15187
28.04.2006, aktualisiert am 03.05.2006
7270
19
0
2 Netzwerke erreichen sich gegenseitig nicht. Von anderen PCs im Internet aber ist aber alles erreichbar. Woran liegts?
Ich hab schon so viel versucht und probiert - hat noch jemand einen Tipp?
Hallo,
folgende Konfiguration:
Es gibt 2 Netzwerke, jedes hinter einem Router (Linksys WRT54 GC) "versteckt".
Beide Netzwerke sind beim gleichen Provider, jedes mit einer festen IP über Richtfunk angebunden.
Hinter jedem Router befinden sich verschiedene "Dienste", die ich per Port-Weiterleitung erreichbar machen möchte. (Z.B. VNC-Weiterleitung, um meiner Schwester Support leisten zu können - sie hat also vom Router ne interne IP, und die Ports leite ich auf ihren PC weiter - so meine Vorstellung).
Das klappte auch schon mal - zufällig, glaube ich, und dann kam irgendwann das Problem:
Ich kann, obwohl am Router korrekt eingestellt, den jeweils anderen Router nicht anpingen, ABER: von Webseiten, die Ping-Dienste hergeben, erreiche ich die beiden Router -> ich nehme also an, dass die Router ansich korrekt eingestellt sind, da sie das Pingen und Tracerouten schonmal nicht blocken.
Ich kann von beiden Routern aus Pings absetzen, nutze also nicht mal einen PC dafür (somit kann ich fehlerhaftes Routing eigentlich ausschließen). Mit diesen Pings erreiche ich (fast) jedes beliebiges Ziel (sofern diese eben nicht Pings blocken). Aber prinzipiell geht es halt.
In dem Netzwerk meines Providers haben alle Kunden feste IPs, und ich kann alle, die online sind, von beiden Routern aus anpingen. Nur eben nicht gegenseitig.
Ich habe so ziemlich alle Konfigurationen durch. Ich weiß nicht weiter. Selbst mein Provider kann sich das nicht erklären; er kam z.B. von seinem PC (der natürlich auch in seinem Netzwerk hängt) problemlos auf die Dienste hinter den Ports - und zwar auf beide Router. Das zeigt doch, dass sie eigentlich korrekt arbeiten, oder lasse ich mich da vielleicht von irgendwas täuschen??
Ich habe hier sämtliche in Frage kommenden Threads durch, aber da die Konfiguration und vor allem das Problem relativ selten ist, wurde ich auch nicht fündig. Es ist ziemlich kniffelig, glaub ich, deswegen verschone ich Euch erstmal mit IPs usw.
Natürlich werde ich auf Anfragen komplette Angaben zu "was auch immer" machen.
Ich bitte Euch um Hilfe, ich bin ratlos...
Danke,
TC
Hallo,
folgende Konfiguration:
Es gibt 2 Netzwerke, jedes hinter einem Router (Linksys WRT54 GC) "versteckt".
Beide Netzwerke sind beim gleichen Provider, jedes mit einer festen IP über Richtfunk angebunden.
Hinter jedem Router befinden sich verschiedene "Dienste", die ich per Port-Weiterleitung erreichbar machen möchte. (Z.B. VNC-Weiterleitung, um meiner Schwester Support leisten zu können - sie hat also vom Router ne interne IP, und die Ports leite ich auf ihren PC weiter - so meine Vorstellung).
Das klappte auch schon mal - zufällig, glaube ich, und dann kam irgendwann das Problem:
Ich kann, obwohl am Router korrekt eingestellt, den jeweils anderen Router nicht anpingen, ABER: von Webseiten, die Ping-Dienste hergeben, erreiche ich die beiden Router -> ich nehme also an, dass die Router ansich korrekt eingestellt sind, da sie das Pingen und Tracerouten schonmal nicht blocken.
Ich kann von beiden Routern aus Pings absetzen, nutze also nicht mal einen PC dafür (somit kann ich fehlerhaftes Routing eigentlich ausschließen). Mit diesen Pings erreiche ich (fast) jedes beliebiges Ziel (sofern diese eben nicht Pings blocken). Aber prinzipiell geht es halt.
In dem Netzwerk meines Providers haben alle Kunden feste IPs, und ich kann alle, die online sind, von beiden Routern aus anpingen. Nur eben nicht gegenseitig.
Ich habe so ziemlich alle Konfigurationen durch. Ich weiß nicht weiter. Selbst mein Provider kann sich das nicht erklären; er kam z.B. von seinem PC (der natürlich auch in seinem Netzwerk hängt) problemlos auf die Dienste hinter den Ports - und zwar auf beide Router. Das zeigt doch, dass sie eigentlich korrekt arbeiten, oder lasse ich mich da vielleicht von irgendwas täuschen??
Ich habe hier sämtliche in Frage kommenden Threads durch, aber da die Konfiguration und vor allem das Problem relativ selten ist, wurde ich auch nicht fündig. Es ist ziemlich kniffelig, glaub ich, deswegen verschone ich Euch erstmal mit IPs usw.
Natürlich werde ich auf Anfragen komplette Angaben zu "was auch immer" machen.
Ich bitte Euch um Hilfe, ich bin ratlos...
Danke,
TC
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 31379
Url: https://administrator.de/contentid/31379
Ausgedruckt am: 15.11.2024 um 15:11 Uhr
19 Kommentare
Neuester Kommentar
hallo turbo,
so wie du das beschreibst, fällt mir eigentlich nur eins ein.
hardware- oder konfigurationsfehler scheinen es ja nicht zu sein.
ein vorschlag: wenn du die möglichkeit hast, mach doch die konfiguration auf einem oder beiden routern nochmal komplett neu.
ich glaub hier hilft dir nur probieren und mir hat's schon geholfen, eine installation oder andres einfach nochmal neu zu machen, auch wenns keine erklärung dafür gibt, oft genug hat sich so das problem gelöst.
dieter
so wie du das beschreibst, fällt mir eigentlich nur eins ein.
hardware- oder konfigurationsfehler scheinen es ja nicht zu sein.
ein vorschlag: wenn du die möglichkeit hast, mach doch die konfiguration auf einem oder beiden routern nochmal komplett neu.
ich glaub hier hilft dir nur probieren und mir hat's schon geholfen, eine installation oder andres einfach nochmal neu zu machen, auch wenns keine erklärung dafür gibt, oft genug hat sich so das problem gelöst.
dieter
Hallo Dieter,
vielen Dank für Deine Antwort.
Neukonfiguration hab ich schon gemacht.
Beide Gerät "hardware-resettet" und alles nochmal neu. Das half leider auch nicht.
Ich werde das aber dennoch gleich nochmal machen. Vielleicht nach dem Motto: einmal ist keinmal
Ich werd dann bald posten, was daraus geworden ist...
TC
Hab nun an meinem Router die Werkseinstellungen geladen und wieder neu konfiguriert.
-> Keine Änderung. Schade
vielen Dank für Deine Antwort.
Neukonfiguration hab ich schon gemacht.
Beide Gerät "hardware-resettet" und alles nochmal neu. Das half leider auch nicht.
Ich werde das aber dennoch gleich nochmal machen. Vielleicht nach dem Motto: einmal ist keinmal
Ich werd dann bald posten, was daraus geworden ist...
TC
Hab nun an meinem Router die Werkseinstellungen geladen und wieder neu konfiguriert.
-> Keine Änderung. Schade
Wie sieht dein Szenario aus ??? Ich verstehe das so:
Netz1-----(Router1)----(Richtfunk)----(Router2)-----Netz2
Wenn du im RiFu Segment feste Adressen fährst musst du die Linksys WRTs auf dem WAN Interface auf "feste IP" manuell setzen und ihnen eine Adresse aus dem Segment vergeben. Per default erlauben die Linksys keinen Ping auf der WAN Seite aus Sicherheitsgründen, das kannst du aber im "Security" Submenü im Setup aktivieren. Damit müssten die Router untereinander pingbar sein. Ferner musst du immer das jeweils andere netzwerk auf der WAN Seite des Routers in dessen statischer Routing Tabelle eintragen, denn die Router machen sich die Netze nicht dynamisch bekannt, da sie keinerlei dynamische Routing protokolle supporten !!!
Da die Router immer die NAT Funktion aktiv haben musst du sämtliche Dienste die über den WAN Port erreichbar sein sollen auf beinen Routern in die Port Forwarding Tabelle eintragen. Dies Funktioniert aber per TCP und UDP Port immer nur für einen Rechner. Dasgleiche gilt auch für Ping (ICMP Packete) für Pings auf Adressen hinter der NAT Funktion.
Ist das transparent sollte es eigentlich klappen.
Netz1-----(Router1)----(Richtfunk)----(Router2)-----Netz2
Wenn du im RiFu Segment feste Adressen fährst musst du die Linksys WRTs auf dem WAN Interface auf "feste IP" manuell setzen und ihnen eine Adresse aus dem Segment vergeben. Per default erlauben die Linksys keinen Ping auf der WAN Seite aus Sicherheitsgründen, das kannst du aber im "Security" Submenü im Setup aktivieren. Damit müssten die Router untereinander pingbar sein. Ferner musst du immer das jeweils andere netzwerk auf der WAN Seite des Routers in dessen statischer Routing Tabelle eintragen, denn die Router machen sich die Netze nicht dynamisch bekannt, da sie keinerlei dynamische Routing protokolle supporten !!!
Da die Router immer die NAT Funktion aktiv haben musst du sämtliche Dienste die über den WAN Port erreichbar sein sollen auf beinen Routern in die Port Forwarding Tabelle eintragen. Dies Funktioniert aber per TCP und UDP Port immer nur für einen Rechner. Dasgleiche gilt auch für Ping (ICMP Packete) für Pings auf Adressen hinter der NAT Funktion.
Ist das transparent sollte es eigentlich klappen.
Hallo aqui,
genaugenommen sieht das Szenario so aus:
Netz1 - R1 - AP1 - Richtfunkstrecke A-B - Netzwerk - Richtfunkstrecke B-C - AP2 - R2 -Netz2
Die Router sind definitiv pingbar (Getestet von Webseiten-Pings). Nur nicht gegenseitig.
Im erweiterten Routing kann ich den Modus auf "Router" und dynamische Routing (RIP) einschalten. Das sollte das Problem auch nicht sein.
Das Port-Forwarding ist schon klar und in Ordnung. Im N1 soll nur VNC speziell auf einen PC führen, eine auf den Router für Remote-Admin und eine auf die Telefonanlage. Im N2 soll VPN, Web und Remote-Konsole laufen. Das klappt ja auch alles. Ich komme von überall an Netz1 und an Netz2 - nur nicht von N1 auf N2 und umgekehrt. Das ist ja das seltsame Phänomen...
Ich habe meinen Router (N2) wieder auf Werkstandard gesetzt und neu konfiguriert - keine Änderung. Es gibt beim Provider einen internen Gateway, der die beiden Richtfunkstrecken anbindet. Möglich, dass der nen Schaden hat?
Und ich muss es - weil es so unglaublich klingt - nochmal sagen:
Es hat schon mal funktioniert... Plötzlich gings dann nicht mehr. Aber niemand hat etwas verstellt. Ich kann mir wirklich nur eine Änderung (oder Defekt) beim Provider vorstellen. Der aber geht über die gleichen Gateways und kommt an meine beiden Netze ran... Ich war ja selbst dabei...
Ich kapier das nicht... Wo soll ich denn noch suchen?
Gruß,
TC
Hier mal die IPs:
N2: 195.243.xx.>128 / 255.255.255.128
R2 intern: 192.168.10.1 / 255.255.255.0; GW 192.168.1.1 (Vorgabe von Provider)
N1: 195.243.xx.>200 / 255.255.255.128
R1 intern: 192.168.0.1 / 255.255.255.0; GW 192.168.1.1 (Vorgabe von Provider)
Wie Du siehst, verwenden die Accesspoints (konfiguriert in Client-Mode), die mit Richtfunkantennen den Kontakt zum Provider aufnehmen, jeweils einen Gateway mit der IP 192.168.1.1.
Deshalb verwende ich intern 0.0 und 10.0
Beide Accesspoint zeigen aufgrund der Örtlichkeit auf verschiedene Antennen, womit Sie auch auf unterschiedlichen Wegen zum Provider kommen. Es ist KEINE direkte Verbindung zwischen den AP's!!
An den AP's hängen dann die Router, die die WAN-IP vom haben.
Ach ja, noch was: Ich hab ja schon erwähnt, dass es anfangs funktionierte. Damals war das aber nur möglich, wenn ich mit dem DNS-Namen gepingt hab. Auf die IP hatte N1 noch nie reagiert. N2 hat keinen DNS, und so komm ich da erst recht nicht ran. Aber N1 reagiert auch auf den DNS mittlerweile nicht mehr. Laut nslookup ist der Name aber noch eingetragen. Hm, wie gesagt, man kommt von überall an beide Netze. Und ich will auch dahin
genaugenommen sieht das Szenario so aus:
Netz1 - R1 - AP1 - Richtfunkstrecke A-B - Netzwerk - Richtfunkstrecke B-C - AP2 - R2 -Netz2
Die Router sind definitiv pingbar (Getestet von Webseiten-Pings). Nur nicht gegenseitig.
Im erweiterten Routing kann ich den Modus auf "Router" und dynamische Routing (RIP) einschalten. Das sollte das Problem auch nicht sein.
Das Port-Forwarding ist schon klar und in Ordnung. Im N1 soll nur VNC speziell auf einen PC führen, eine auf den Router für Remote-Admin und eine auf die Telefonanlage. Im N2 soll VPN, Web und Remote-Konsole laufen. Das klappt ja auch alles. Ich komme von überall an Netz1 und an Netz2 - nur nicht von N1 auf N2 und umgekehrt. Das ist ja das seltsame Phänomen...
Ich habe meinen Router (N2) wieder auf Werkstandard gesetzt und neu konfiguriert - keine Änderung. Es gibt beim Provider einen internen Gateway, der die beiden Richtfunkstrecken anbindet. Möglich, dass der nen Schaden hat?
Und ich muss es - weil es so unglaublich klingt - nochmal sagen:
Es hat schon mal funktioniert... Plötzlich gings dann nicht mehr. Aber niemand hat etwas verstellt. Ich kann mir wirklich nur eine Änderung (oder Defekt) beim Provider vorstellen. Der aber geht über die gleichen Gateways und kommt an meine beiden Netze ran... Ich war ja selbst dabei...
Ich kapier das nicht... Wo soll ich denn noch suchen?
Gruß,
TC
Hier mal die IPs:
N2: 195.243.xx.>128 / 255.255.255.128
R2 intern: 192.168.10.1 / 255.255.255.0; GW 192.168.1.1 (Vorgabe von Provider)
N1: 195.243.xx.>200 / 255.255.255.128
R1 intern: 192.168.0.1 / 255.255.255.0; GW 192.168.1.1 (Vorgabe von Provider)
Wie Du siehst, verwenden die Accesspoints (konfiguriert in Client-Mode), die mit Richtfunkantennen den Kontakt zum Provider aufnehmen, jeweils einen Gateway mit der IP 192.168.1.1.
Deshalb verwende ich intern 0.0 und 10.0
Beide Accesspoint zeigen aufgrund der Örtlichkeit auf verschiedene Antennen, womit Sie auch auf unterschiedlichen Wegen zum Provider kommen. Es ist KEINE direkte Verbindung zwischen den AP's!!
An den AP's hängen dann die Router, die die WAN-IP vom haben.
Ach ja, noch was: Ich hab ja schon erwähnt, dass es anfangs funktionierte. Damals war das aber nur möglich, wenn ich mit dem DNS-Namen gepingt hab. Auf die IP hatte N1 noch nie reagiert. N2 hat keinen DNS, und so komm ich da erst recht nicht ran. Aber N1 reagiert auch auf den DNS mittlerweile nicht mehr. Laut nslookup ist der Name aber noch eingetragen. Hm, wie gesagt, man kommt von überall an beide Netze. Und ich will auch dahin
Mmmhhh. Nun hast du die Verwirrung komplett gemacht:
"Das klappt ja auch alles. Ich komme von überall an Netz1 und an Netz2 - nur nicht von N1 auf N2 und umgekehrt. Das ist ja das seltsame Phänomen..."
Was geht denn nun und was nicht, der Satz von oben ist verwirrend ???
Im Grunde genommen aber ist das Wichtigste die Klärung der Frage wie die Wireless (RiFu) Strecke arbeitet ! Aus IP Sicht sollte das dann so aussehen (Annahme xx ist 33) :
N2=195.243.33.0/25----(Router u. AP)-----192.168.10.0/25---(Carrier Router ???)---192.168.0.0/25----(Router u.AP)----N1=195.243.33.128/25
Aus routingtechnischer Sicht liegt der Fehler auf der Providerseite in der RiFu Strecke, denn hier hat der eine Router das RFC 1918 Class-C Netz 192.168.0.0 und der andere 192.168.10.0
Das würde so nie funktionieren zumal der Carrier auch noch ein und dasselbe Gateway auf der RiFu Strecke vergeben hat. Eigentlich unsinning wenn die Funkverbindung Layer 2 transparent ist, denn dann dürfte hier nur ein einziges IP Netz dazwischen sein. Auch wenn du auf Carrierseite auf unterschiedliche Zugangspunkte gehst.
Sinn würde dies nur machen wenn der Carrier einen Router zwischen diesen beiden Class-C Netzen betreibt nur dann sind wieder die Gateway Angaben unsinnig. Auf der einen Seite müsste das dann 192.169.0.1 auf der anderen 192.168.10.1 z.B. sein aber niemals 192.168.1.1 auf beiden Seiten !!! Zumal diese Adresse noch in einem völlig unterschiedlichen Subnetz liegt was an deinen Routern gar nicht angeschlossen ist !!!
Der Carrier hat dir 3 unterschiedliche Netzadressen ohne Bezug dort gegeben und das macht die Sache undurchsichtig.
Möglichkeit A
(Der Carrier routet zwischen dem 192.168.0.0er und 192.168.10.0er Netz)
Ist dies der Fall wäre die Gatewayadresse auf dem RiFu Link falsch, denn hier müsste das bei Router 1 eine Gateway Adresse im 192.168.0.0er Netz sein und auf Router 2 eine im 192.168.10.0er Netz sein. Also da wären die Gateway IPs komplett falsch wie oben schon beschrieben.
Möglichkeit B
Das Rifu Netz ist Layer 2 transparent.
Dann wären die IP Netze auf der RiFu Seite einfach falsch bzw. eins zuviel (die Gateway Angaben sowieso) denn dann ist zwischen den beiden Router nur ein einziges IP Netz. Ein Gateway wäre dann überflüssig.
Eine Sache ist auch noch generell unverständlich: Die RiFu Strecke müsste komplett vom Internet getrennt sein, denn du benutzt auf den LAN Netzwerken öffentliche Adressen (195.243...) die dürften sowieso nicht offen übers Internet geroutet werden (es sei denn sie sind auf dich registriert..) und wenn dann nur über ein VPN. Dazwischen RFC 1918 Adressen....schon etwas ungewöhnlich für einen Provider.
Fazit: Die RiFu Adresse bzw. Netzwerkvergabe ist verworren und kann nach normalen IP Designrichtlinien nicht richtig sein.
Sofern du da nicht etwas mehr Licht ins Dunkel bringst wird ein Troubleshooting sehr schwer.....
"Das klappt ja auch alles. Ich komme von überall an Netz1 und an Netz2 - nur nicht von N1 auf N2 und umgekehrt. Das ist ja das seltsame Phänomen..."
Was geht denn nun und was nicht, der Satz von oben ist verwirrend ???
Im Grunde genommen aber ist das Wichtigste die Klärung der Frage wie die Wireless (RiFu) Strecke arbeitet ! Aus IP Sicht sollte das dann so aussehen (Annahme xx ist 33) :
N2=195.243.33.0/25----(Router u. AP)-----192.168.10.0/25---(Carrier Router ???)---192.168.0.0/25----(Router u.AP)----N1=195.243.33.128/25
Aus routingtechnischer Sicht liegt der Fehler auf der Providerseite in der RiFu Strecke, denn hier hat der eine Router das RFC 1918 Class-C Netz 192.168.0.0 und der andere 192.168.10.0
Das würde so nie funktionieren zumal der Carrier auch noch ein und dasselbe Gateway auf der RiFu Strecke vergeben hat. Eigentlich unsinning wenn die Funkverbindung Layer 2 transparent ist, denn dann dürfte hier nur ein einziges IP Netz dazwischen sein. Auch wenn du auf Carrierseite auf unterschiedliche Zugangspunkte gehst.
Sinn würde dies nur machen wenn der Carrier einen Router zwischen diesen beiden Class-C Netzen betreibt nur dann sind wieder die Gateway Angaben unsinnig. Auf der einen Seite müsste das dann 192.169.0.1 auf der anderen 192.168.10.1 z.B. sein aber niemals 192.168.1.1 auf beiden Seiten !!! Zumal diese Adresse noch in einem völlig unterschiedlichen Subnetz liegt was an deinen Routern gar nicht angeschlossen ist !!!
Der Carrier hat dir 3 unterschiedliche Netzadressen ohne Bezug dort gegeben und das macht die Sache undurchsichtig.
Möglichkeit A
(Der Carrier routet zwischen dem 192.168.0.0er und 192.168.10.0er Netz)
Ist dies der Fall wäre die Gatewayadresse auf dem RiFu Link falsch, denn hier müsste das bei Router 1 eine Gateway Adresse im 192.168.0.0er Netz sein und auf Router 2 eine im 192.168.10.0er Netz sein. Also da wären die Gateway IPs komplett falsch wie oben schon beschrieben.
Möglichkeit B
Das Rifu Netz ist Layer 2 transparent.
Dann wären die IP Netze auf der RiFu Seite einfach falsch bzw. eins zuviel (die Gateway Angaben sowieso) denn dann ist zwischen den beiden Router nur ein einziges IP Netz. Ein Gateway wäre dann überflüssig.
Eine Sache ist auch noch generell unverständlich: Die RiFu Strecke müsste komplett vom Internet getrennt sein, denn du benutzt auf den LAN Netzwerken öffentliche Adressen (195.243...) die dürften sowieso nicht offen übers Internet geroutet werden (es sei denn sie sind auf dich registriert..) und wenn dann nur über ein VPN. Dazwischen RFC 1918 Adressen....schon etwas ungewöhnlich für einen Provider.
Fazit: Die RiFu Adresse bzw. Netzwerkvergabe ist verworren und kann nach normalen IP Designrichtlinien nicht richtig sein.
Sofern du da nicht etwas mehr Licht ins Dunkel bringst wird ein Troubleshooting sehr schwer.....
Hallo,
vielen Dank für diese sehr ausführliche Erläuterung.
Soll ich es mit einem Bild probieren? Vielleicht vereinfacht das die Sache...
Ich versuche es nochmal, einfach zu erklären.
Mein Provider gibt mir einen Internetzugang mit öffentlicher IP (195.243.xx.>128 / 255.255.255.128). Dieser Zugang sieht so aus:
Ich muss für die RF-Strecke einen Accesspoint haben, im Client-Mode. Dahinter kann normalerweise ein PC, der die öffentliche IP bekommt (über die beim Provider registrierte MAC ist das System vor Missbrauch geschützt).
So, nun hab ich aber nicht einen PC, sondern 2, einen Laptop, einen Linuxserver und eine Fritzbox. Also brauch ich 5 interne IPs und einen Router.
In diesem Fall erhält der Router
- als WAN-Adresse die 195.243.xx.xxx / 255.255.255.128
- als Gateway die 192.168.1.1, DNS kann ich mir aussuchen, hier ist der vom Provider eingestellt (195.243.xx.x)
Die PCs und co. bekommen 192.168.0.x-Adressen.
Soweit klar? Damit ist mein Internetzugang erledigt. Ich komme raus, und alle kommen rein, sofern sie es schaffen. Natürlich sind hier nur der VPN-Port und welche für die Fritzbox freigeschaltet.
Nun stelle man sich vor, man kopiere die komplette Anlage (auch identische Geräte und Konfigurationen) und stelle die bei meiner Schwester auf -> andere Straße, sie muss auf ne andere Antenne. Alles, was anders ist, ist einfach nur die IP. Natürlich ist die auch öffentlich, muss ja (jeder Internetanschluss hat ja letztlich eine öffentliche IP - oder routen Provider auch auf auf 192er?? Hm, wäre mir neu, aber machbar wärs ja... egal, hier gibts öffentliche, feste IPs mit fester MAC). Ah, doch, noch ein Unterschied: Bei meiner Schwester verwende ich intern 192.168.10.x-Adressen (einfach, um meine Liste der IPs, Ports und Passwörter etwas zu vereinfachen - ich muss mir das alles notieren, und da ist es einfacher, wenn nicht zwei das gleiche Netz haben. Das ist alles (unsere Fritzboxen haben immer die .5 am Ende, die PCs haben interne IPs als Abkürzung der Taktfrequenz - so kann ich mir die Konfigurationen einfach besser merken. Ich erwähn das deshalb, weil ich denke, dass das alles nichts damit zu tun haben kann, warum der eine Router den anderen Router nicht anpingen kann. Wenn ich nun alle PCs abschalte, und nur einen einsetze, um per Web-Konsole vom Router selbst einen Ping abzuschicken, hat das ja mit dem internen Netzwerk ansich garnichts zu tun)
Nun möchte ich bei meiner Schwester nicht VPN reinrouten, sondern VNC oder Remotekonsole, und auch deren Fritzbox. Funktioniert auch alles. Wenn ich Euch jetzt IP, Port und Passwort nenne, könntet Ihr meiner Schwester zuschauen, was sie am PC macht. Oder zu mir ins Netz, wenn ich Euch nen VPN-Zugang freischalte. Geht auch.
Was nicht geht, ist eben, von meinem Router zu ihrem, und von ihrem zu meinem Router. Diese Verbindung kommt nicht zustande. Schalt ich Apache ein und öffne die 80, kommt die ganze Welt an meinen Webserver, nur nicht meine Schwester. Sie erhält schlicht keine Route zu meiner IP.
ABER, und das ist ja auch seltsam: pingt einer von uns jemand anderen im Netzwerk unseres Providers an (195.243.xx.1-253), bekommen wir Replys, sofern die Leute online sind.
Ich ziehe wirklich in Erwägung, Traceroutes hier einzufügen...
Routenverfolgung zu Zielrechner - NS meines Providers [195.243.xx.x] über maximal 30 Abschnitte:
1 1 ms 1 ms 1 ms 195.243.xx.xxx (das ist meine IP)
2 82 ms 77 ms 66 ms 192.168.1.1
3 68 ms 77 ms 56 ms 192.168.0.3
4 78 ms 36 ms 44 ms Zielrechner [195.243.xx.x]
Ablaufverfolgung beendet.
Diese 192.168.0.3 ist ein internes Gateway bei meinem Provider. Aber alle anderen gehen ja auch darüber, er kanns also nicht Schuld sein, da ich andere User und z.B. auch die Server meines Providers anpingen kann - wie man sieht.
Hier nun, was passiert, wenn ich "meine Schwester" anpinge:
Routenverfolgung zu Router meiner Schwester [195.243.xx.yyy] über maximal 30 Absch
nitte:
1 1 ms 1 ms 1 ms 195.243.xx.xxx (wieder meine IP - klar)
2 * * * Zeitüberschreitung der Anforderung.
3 * * * Zeitüberschreitung der Anforderung.
4 * * * Zeitüberschreitung der Anforderung.
Sorry, ich weiß nicht, wie ich es noch beschreiben soll. Das alles hier ist historisch gewachsen und nicht ganz einfach. Mit den seltsamen Routen bei meinem Provider machts mir das Leben auch nicht leichter. Ich kann nur sagen: Jeder kann mit jedem, nur unsere beiden Router finden sich gegenseitig nicht... Als gäbs ne Sperre, nur zwischen diesen beiden IPs. Aber mein Provider sieht das anders...
Ich hoffe, ich habs verständlich formuliert. Vielleicht machts die Masse
, ich weiß es nicht.
Ich leg mal ne Grafik an und stell sie online.
lG,
TC
vielen Dank für diese sehr ausführliche Erläuterung.
Soll ich es mit einem Bild probieren? Vielleicht vereinfacht das die Sache...
Ich versuche es nochmal, einfach zu erklären.
Mein Provider gibt mir einen Internetzugang mit öffentlicher IP (195.243.xx.>128 / 255.255.255.128). Dieser Zugang sieht so aus:
Ich muss für die RF-Strecke einen Accesspoint haben, im Client-Mode. Dahinter kann normalerweise ein PC, der die öffentliche IP bekommt (über die beim Provider registrierte MAC ist das System vor Missbrauch geschützt).
So, nun hab ich aber nicht einen PC, sondern 2, einen Laptop, einen Linuxserver und eine Fritzbox. Also brauch ich 5 interne IPs und einen Router.
In diesem Fall erhält der Router
- als WAN-Adresse die 195.243.xx.xxx / 255.255.255.128
- als Gateway die 192.168.1.1, DNS kann ich mir aussuchen, hier ist der vom Provider eingestellt (195.243.xx.x)
Die PCs und co. bekommen 192.168.0.x-Adressen.
Soweit klar? Damit ist mein Internetzugang erledigt. Ich komme raus, und alle kommen rein, sofern sie es schaffen. Natürlich sind hier nur der VPN-Port und welche für die Fritzbox freigeschaltet.
Nun stelle man sich vor, man kopiere die komplette Anlage (auch identische Geräte und Konfigurationen) und stelle die bei meiner Schwester auf -> andere Straße, sie muss auf ne andere Antenne. Alles, was anders ist, ist einfach nur die IP. Natürlich ist die auch öffentlich, muss ja (jeder Internetanschluss hat ja letztlich eine öffentliche IP - oder routen Provider auch auf auf 192er?? Hm, wäre mir neu, aber machbar wärs ja... egal, hier gibts öffentliche, feste IPs mit fester MAC). Ah, doch, noch ein Unterschied: Bei meiner Schwester verwende ich intern 192.168.10.x-Adressen (einfach, um meine Liste der IPs, Ports und Passwörter etwas zu vereinfachen - ich muss mir das alles notieren, und da ist es einfacher, wenn nicht zwei das gleiche Netz haben. Das ist alles (unsere Fritzboxen haben immer die .5 am Ende, die PCs haben interne IPs als Abkürzung der Taktfrequenz - so kann ich mir die Konfigurationen einfach besser merken. Ich erwähn das deshalb, weil ich denke, dass das alles nichts damit zu tun haben kann, warum der eine Router den anderen Router nicht anpingen kann. Wenn ich nun alle PCs abschalte, und nur einen einsetze, um per Web-Konsole vom Router selbst einen Ping abzuschicken, hat das ja mit dem internen Netzwerk ansich garnichts zu tun)
Nun möchte ich bei meiner Schwester nicht VPN reinrouten, sondern VNC oder Remotekonsole, und auch deren Fritzbox. Funktioniert auch alles. Wenn ich Euch jetzt IP, Port und Passwort nenne, könntet Ihr meiner Schwester zuschauen, was sie am PC macht. Oder zu mir ins Netz, wenn ich Euch nen VPN-Zugang freischalte. Geht auch.
Was nicht geht, ist eben, von meinem Router zu ihrem, und von ihrem zu meinem Router. Diese Verbindung kommt nicht zustande. Schalt ich Apache ein und öffne die 80, kommt die ganze Welt an meinen Webserver, nur nicht meine Schwester. Sie erhält schlicht keine Route zu meiner IP.
ABER, und das ist ja auch seltsam: pingt einer von uns jemand anderen im Netzwerk unseres Providers an (195.243.xx.1-253), bekommen wir Replys, sofern die Leute online sind.
Ich ziehe wirklich in Erwägung, Traceroutes hier einzufügen...
Routenverfolgung zu Zielrechner - NS meines Providers [195.243.xx.x] über maximal 30 Abschnitte:
1 1 ms 1 ms 1 ms 195.243.xx.xxx (das ist meine IP)
2 82 ms 77 ms 66 ms 192.168.1.1
3 68 ms 77 ms 56 ms 192.168.0.3
4 78 ms 36 ms 44 ms Zielrechner [195.243.xx.x]
Ablaufverfolgung beendet.
Diese 192.168.0.3 ist ein internes Gateway bei meinem Provider. Aber alle anderen gehen ja auch darüber, er kanns also nicht Schuld sein, da ich andere User und z.B. auch die Server meines Providers anpingen kann - wie man sieht.
Hier nun, was passiert, wenn ich "meine Schwester" anpinge:
Routenverfolgung zu Router meiner Schwester [195.243.xx.yyy] über maximal 30 Absch
nitte:
1 1 ms 1 ms 1 ms 195.243.xx.xxx (wieder meine IP - klar)
2 * * * Zeitüberschreitung der Anforderung.
3 * * * Zeitüberschreitung der Anforderung.
4 * * * Zeitüberschreitung der Anforderung.
Sorry, ich weiß nicht, wie ich es noch beschreiben soll. Das alles hier ist historisch gewachsen und nicht ganz einfach. Mit den seltsamen Routen bei meinem Provider machts mir das Leben auch nicht leichter. Ich kann nur sagen: Jeder kann mit jedem, nur unsere beiden Router finden sich gegenseitig nicht... Als gäbs ne Sperre, nur zwischen diesen beiden IPs. Aber mein Provider sieht das anders...
Ich hoffe, ich habs verständlich formuliert. Vielleicht machts die Masse
, ich weiß es nicht.Ich leg mal ne Grafik an und stell sie online.
lG,
TC
hier die grafik:
195.243.14.206/gif_1.gif
ok, ich kann wohl keinen gescheiten link einfügen... na, ihr wißt ja, wie's geht
195.243.14.206/gif_1.gif
ok, ich kann wohl keinen gescheiten link einfügen... na, ihr wißt ja, wie's geht
Jetzt habe ichs verstanden
Es ist also letztlich die Kopplung der beiden Netze 192.168.0.0/24 und 192.168.10.0/24 über das öffentliche Segment des Carriers 195.243.14.0/25.
Achtung: bei dem öffentlichen Segment hast du eine 25 Bit Subnetmaske !! Deine beiden Router müssen sich mit dem öffentlichen Bein im Adressbereich .1 bis .127 oder .129 bis .254 befinden ! Das ist sehr wichtig sonst würde eh nichts funktionieren, aber das scheint ja zu klappen, da du alles pingen kannst untereinander in diesem Bereich.
Die Grundproblematik des ganzen Designs ist das du an beiden Enden RFC 1918 Netze hast die im Internet nicht geroutet werden ! Alle Carrier haben auf ihren Eingangssystemen (Router, Switches) entsprechende Accesslisten, die diese Netze wegfiltern in das digitale Nirwana lenken. Eine direkte klassische Routing Kopplung wird also dadurch niemals möglich sein.
Ein Ping hätte im IP Header ja dann immer entweder die Absender- oder Zieladresse aus dem RFC 1918 192.168er Bereich und da würde dann sofort wieder der Filter zuschlagen. Diese Lösung einer klassichen Routing Kopplung der Netze ist also völlig unmöglich, auch wenn du deinen Routern diese Netze in einer statische Routing Tabelle einträgst. Problem wird immer sein das der Carrier diese RFC 1918 Netze nicht zulässt in der Übertragung.
So ist es auch klar, das du nur lediglich die WAN IP Adressen der Router pingen kannst niemals aber die der 192.168er LAN Segmente hinter den Routern !
Fazit: Du hast nur 2 Optionen:
1.) Portforwarding für einzelne Systeme mit einzelnen Ports
2.) Ein VPN über das öffentliche Internet des Carriers
Ich denke ersteres machst du schon und das klappt. Das kann aber immer nur für einzelne Ports auf einzelne Adressen gehen und niemals für eine Gruppe von Rechnern, da du ja von der einen Adresse des Carriers am Router abhängig bist.
Für eine transparente Kopplung beider Netze kommst du um ein VPN nicht herum, dann hast du aber ein transparent geroutetes Netz über den VPN Tunnel in dem dann "jeder mit jedem kann"...
Es ist also letztlich die Kopplung der beiden Netze 192.168.0.0/24 und 192.168.10.0/24 über das öffentliche Segment des Carriers 195.243.14.0/25.
Achtung: bei dem öffentlichen Segment hast du eine 25 Bit Subnetmaske !! Deine beiden Router müssen sich mit dem öffentlichen Bein im Adressbereich .1 bis .127 oder .129 bis .254 befinden ! Das ist sehr wichtig sonst würde eh nichts funktionieren, aber das scheint ja zu klappen, da du alles pingen kannst untereinander in diesem Bereich.
Die Grundproblematik des ganzen Designs ist das du an beiden Enden RFC 1918 Netze hast die im Internet nicht geroutet werden ! Alle Carrier haben auf ihren Eingangssystemen (Router, Switches) entsprechende Accesslisten, die diese Netze wegfiltern in das digitale Nirwana lenken. Eine direkte klassische Routing Kopplung wird also dadurch niemals möglich sein.
Ein Ping hätte im IP Header ja dann immer entweder die Absender- oder Zieladresse aus dem RFC 1918 192.168er Bereich und da würde dann sofort wieder der Filter zuschlagen. Diese Lösung einer klassichen Routing Kopplung der Netze ist also völlig unmöglich, auch wenn du deinen Routern diese Netze in einer statische Routing Tabelle einträgst. Problem wird immer sein das der Carrier diese RFC 1918 Netze nicht zulässt in der Übertragung.
So ist es auch klar, das du nur lediglich die WAN IP Adressen der Router pingen kannst niemals aber die der 192.168er LAN Segmente hinter den Routern !
Fazit: Du hast nur 2 Optionen:
1.) Portforwarding für einzelne Systeme mit einzelnen Ports
2.) Ein VPN über das öffentliche Internet des Carriers
Ich denke ersteres machst du schon und das klappt. Das kann aber immer nur für einzelne Ports auf einzelne Adressen gehen und niemals für eine Gruppe von Rechnern, da du ja von der einen Adresse des Carriers am Router abhängig bist.
Für eine transparente Kopplung beider Netze kommst du um ein VPN nicht herum, dann hast du aber ein transparent geroutetes Netz über den VPN Tunnel in dem dann "jeder mit jedem kann"...
Hi aqui,
die beiden Router befinden sich zwischen 129 und 254 (einen davon kennst du ja jetzt )
Ich kann ja von Router zu Router nicht mal pingen...
Also, die Router haben eine Admin-Webconsole (ist Dir sicher nicht neu...). Auf dieser Console kann ich Pings abschicken. Soweit ich dies den Beschreibungen nicht entnehmen kann, wird mit der externen IP gepingt. Somit kann ein zurückschicken des angepingten Routers an die öffentliche IP des pingenden Routers doch kein Problem sein, oder?
Zu den 2 Optionen:
1. Portforwarding für die einzelnen Dienste... klar, funktioniert ja auch
2. das VPN funktioniert ja auch schon. Für alle außer meiner Schwester's Anlage.
Die Netze sollen überdies nicht dauernd verbunden sein. Sie soll sich bei mir per VPN einwählen können, und ich soll mich bei Bedarf per VNC auf Ihren Desktop klemmen. Der Rest mit den Fritzboxen ist ja keine Verbindung der Netze, sondern jede Fritzbox für sich mit sipgate.
Und bei mir wird bei Bedarf (so wie im Moment) ein Webserver aktiviert. (Wie Du siehst, auch dies geht ja schon soweit)
Mal was anderes zu der Sache:
Die Router unterstützen sowohl Gateway-Modus, Router-Modus, und letzteren mit oder ohne RIP.
Auch wenn ich glaube, die Erklärungen und damit die Unterschiede dazu verstanden zu haben, kannst Du mir vielleicht erklären, wieso keine der Einstellungen unterschiedliche Wirkungen hat? In einem Fall (Gateway-Modus) wird doch NAT verwendet, oder?
Damit sollte doch auch das Anpingen von meinem PC (anstatt von Router-Webconsole) zu dem Router meiner Schwester auch kein Problem sein.
Dass ich von meinem PC ihren PC nicht anpingen klar, das ist logisch (ich müßte schon den Ping-Port forwarden, wär ja Quatsch...).
Nochmals danke für Deine gute Unterstützung!!
Gruß,
TC
die beiden Router befinden sich zwischen 129 und 254 (einen davon kennst du ja jetzt
)Ich kann ja von Router zu Router nicht mal pingen...
Also, die Router haben eine Admin-Webconsole (ist Dir sicher nicht neu...). Auf dieser Console kann ich Pings abschicken. Soweit ich dies den Beschreibungen nicht entnehmen kann, wird mit der externen IP gepingt. Somit kann ein zurückschicken des angepingten Routers an die öffentliche IP des pingenden Routers doch kein Problem sein, oder?
Zu den 2 Optionen:
1. Portforwarding für die einzelnen Dienste... klar, funktioniert ja auch
2. das VPN funktioniert ja auch schon. Für alle außer meiner Schwester's Anlage.
Die Netze sollen überdies nicht dauernd verbunden sein. Sie soll sich bei mir per VPN einwählen können, und ich soll mich bei Bedarf per VNC auf Ihren Desktop klemmen. Der Rest mit den Fritzboxen ist ja keine Verbindung der Netze, sondern jede Fritzbox für sich mit sipgate.
Und bei mir wird bei Bedarf (so wie im Moment) ein Webserver aktiviert. (Wie Du siehst, auch dies geht ja schon soweit)
Mal was anderes zu der Sache:
Die Router unterstützen sowohl Gateway-Modus, Router-Modus, und letzteren mit oder ohne RIP.
Auch wenn ich glaube, die Erklärungen und damit die Unterschiede dazu verstanden zu haben, kannst Du mir vielleicht erklären, wieso keine der Einstellungen unterschiedliche Wirkungen hat? In einem Fall (Gateway-Modus) wird doch NAT verwendet, oder?
Damit sollte doch auch das Anpingen von meinem PC (anstatt von Router-Webconsole) zu dem Router meiner Schwester auch kein Problem sein.
Dass ich von meinem PC ihren PC nicht anpingen klar, das ist logisch (ich müßte schon den Ping-Port forwarden, wär ja Quatsch...).
Nochmals danke für Deine gute Unterstützung!!
Gruß,
TC
Hi Turbocyclone
Ja der Webserver funktioniert klasse
Ich meine ich kenne den Grund warum du die Router untereinander nicht pingen kannst. Das Problem wird in der Verwendung der IP Quelladresse liege. Wenn du von einem Router zum anderen pingst wird dieser mit an Sicherheit grenzender Wahrscheinlichkeit als Source IP-Adresse im ICMP Packet die des internen LANs nehmen und schon nimmt das Unglück seinen Lauf. Taucht die in Packeten auf die über das Carrier Netzgehen werden die mit Sicherheit gefiltert da diese 1918ner Adressen nicht geroutet werden im Internet. Auch wenn sie doch ans Ziel gelangen sollten muss dieser Router Source und Destination IP vertauschen für sein ICMP echo reply was er dann zurückschickt und da steht dann wieder eine 192.168er RFC 1918 Adresse im IP Header und die fliegt sicher raus. Normalerweise wird alles RFC 1918 seitige, egal ob Source oder Destination, bei ISPs rausgefiltert... gnadenlos.
Was noch sein kann ist, das der ISP ICMP echo und echo reply aus Sicherheitsgründen komplett filtert auf dem Wireless Segment. Meist wird sowas gemacht um "Ping of Death" usw. zu unterbinden und andere Störquellen. Ist also ebenfalls sehr wahrscheinlich. Der ISP könnte dies auch nachträglich eingerichtet haben, dafür spricht das es früher einmal funktionierte.
Um dann die Verbindung zu testen könnte man einmal temporär den Setup Port 80 auf dem WAN Interface freigeben und eine Telnet Verbindung auf den Port 80 aufbauen. Da müsstest du dann einen ASCII Reply vom Konfig Webserver des Routers zurückbekommen. Klappt das ist es wohl ziemlich sicher das ICMP echo durch ACLs geblockt wird.
Zur "anderen Sache": Ja, normalerweise ist der "Gateway Modus" Routing mit NAT und "Router" ohne NAT obwohl diese Nomenklatur auch nicht ganz korrekt ist aber egal..... Es ist aber letztlich immer herstellerabhängig was die mit Ihren Modi meinen. Da gibt es schon so manche "Stilblüten".
Du musst ja immer NAT machen sonst kommst du nie über das öffentliche Segment rüber ohne ein VPN. Klar, ein Ping von einem Endgerät wird auch "genattet" so das du Endgeräte im öffentlichen Internet pingen kannst, denn für die kommt der Ping von deiner öffentlichen Routeradresse im 195.243er Bereich. Das klappt sicher. Allerdings kannst du niemals so in das LAN deiner Schwester pingen, denn hier sind ja RFC 1918er Adressen vergeben außerdem schlägt dann sofort der ISP Filter zu (siehe oben...) wenn du die als Zieladresse angeben solltest.
Das einzige was du machen kannst, ist den Router auf der anderen Seite am WAN Bein (öffentliche IP) zu pingen und dem ein Forwarding einzustellen auf einen Host im LAN dahinter. Das zeigt dir auch gleichzeitig das Dilemma auf in dem man steckt mit IP Forwarding. Das kannst du immer nur für einen einzigen Host hinter dem Router einstellen ! ICMP Forwarding wird wahrscheinlich sowieso nicht gehen, da der Router immer selber darauf antworten will. Ich meine mit Consumer Routern geht das ICMP Forwarding nicht, habe es aber noch nicht aktiv probiert.
Pingen untereinader über eine VPN Verbindung sollte aber problemlos klappen. Dann unterhalten sich deine beiden 192.168er Netze im Tunnel ja direkt miteinander und keiner "sieht" was von den 192.168er Adressen
Ja der Webserver funktioniert klasse
Ich meine ich kenne den Grund warum du die Router untereinander nicht pingen kannst. Das Problem wird in der Verwendung der IP Quelladresse liege. Wenn du von einem Router zum anderen pingst wird dieser mit an Sicherheit grenzender Wahrscheinlichkeit als Source IP-Adresse im ICMP Packet die des internen LANs nehmen und schon nimmt das Unglück seinen Lauf. Taucht die in Packeten auf die über das Carrier Netzgehen werden die mit Sicherheit gefiltert da diese 1918ner Adressen nicht geroutet werden im Internet. Auch wenn sie doch ans Ziel gelangen sollten muss dieser Router Source und Destination IP vertauschen für sein ICMP echo reply was er dann zurückschickt und da steht dann wieder eine 192.168er RFC 1918 Adresse im IP Header und die fliegt sicher raus. Normalerweise wird alles RFC 1918 seitige, egal ob Source oder Destination, bei ISPs rausgefiltert... gnadenlos.
Was noch sein kann ist, das der ISP ICMP echo und echo reply aus Sicherheitsgründen komplett filtert auf dem Wireless Segment. Meist wird sowas gemacht um "Ping of Death" usw. zu unterbinden und andere Störquellen. Ist also ebenfalls sehr wahrscheinlich. Der ISP könnte dies auch nachträglich eingerichtet haben, dafür spricht das es früher einmal funktionierte.
Um dann die Verbindung zu testen könnte man einmal temporär den Setup Port 80 auf dem WAN Interface freigeben und eine Telnet Verbindung auf den Port 80 aufbauen. Da müsstest du dann einen ASCII Reply vom Konfig Webserver des Routers zurückbekommen. Klappt das ist es wohl ziemlich sicher das ICMP echo durch ACLs geblockt wird.
Zur "anderen Sache": Ja, normalerweise ist der "Gateway Modus" Routing mit NAT und "Router" ohne NAT obwohl diese Nomenklatur auch nicht ganz korrekt ist aber egal..... Es ist aber letztlich immer herstellerabhängig was die mit Ihren Modi meinen. Da gibt es schon so manche "Stilblüten".
Du musst ja immer NAT machen sonst kommst du nie über das öffentliche Segment rüber ohne ein VPN. Klar, ein Ping von einem Endgerät wird auch "genattet" so das du Endgeräte im öffentlichen Internet pingen kannst, denn für die kommt der Ping von deiner öffentlichen Routeradresse im 195.243er Bereich. Das klappt sicher. Allerdings kannst du niemals so in das LAN deiner Schwester pingen, denn hier sind ja RFC 1918er Adressen vergeben außerdem schlägt dann sofort der ISP Filter zu (siehe oben...) wenn du die als Zieladresse angeben solltest.
Das einzige was du machen kannst, ist den Router auf der anderen Seite am WAN Bein (öffentliche IP) zu pingen und dem ein Forwarding einzustellen auf einen Host im LAN dahinter. Das zeigt dir auch gleichzeitig das Dilemma auf in dem man steckt mit IP Forwarding. Das kannst du immer nur für einen einzigen Host hinter dem Router einstellen ! ICMP Forwarding wird wahrscheinlich sowieso nicht gehen, da der Router immer selber darauf antworten will. Ich meine mit Consumer Routern geht das ICMP Forwarding nicht, habe es aber noch nicht aktiv probiert.
Pingen untereinader über eine VPN Verbindung sollte aber problemlos klappen. Dann unterhalten sich deine beiden 192.168er Netze im Tunnel ja direkt miteinander und keiner "sieht" was von den 192.168er Adressen
Hallo aqui,
vielen Dank für Dein Posting.
Du schreibst "Wenn du von einem Router zum anderen pingst wird dieser mit an Sicherheit grenzender Wahrscheinlichkeit als Source IP-Adresse im ICMP Packet die des internen LANs nehmen und schon nimmt das Unglück seinen Lauf."
Das müßte ich doch testen können, oder? Ich glaube, mit iptraf (unter Linux) würde man sehen, wenn ich ihn anpinge, gell? Du hast nicht zufällig einen Linux-Rechner, den ich mal anpingen könnte?
Deine andere Idee gefällt mir eigentlich auch, aber auch das können wir sicherlich ausschließen:
Die Sache mit dem ICMP echo und -reply. Denn wenn er das machen würde, wieso kann ich dann alle anderen Teilnehmer seines Netzwerks anpingen? Er müßte den Filter schon auf unsere 2 IPs legen, und das hat er nicht. Der ISP-Verantworliche ist ein entfernter Verwandter, ich bin Per-Du mit ihm und kann es mir nicht vorstellen. Er hätte doch keinen Vorteil davon, denn wir haben beide recht teure Volumentarife, alles was über die Antenne geht, auch von mir zu meiner Schwester (was ihn als ISP also keinen Traffic bei der DTAG kostet), kostet Geld. Wozu sollte er diesen Umstand machen? Und noch ein Argument:
Du kommst doch auf meinen Webserver. Wieso kommt meine Schwester nicht dran? Der ISP müßte doch demnach auch Port 80 sperren. Hat er aber nicht. Meine Schwester kann auch surfen, und wenn ich ihren Port 80 auf den PC leite, kommt man auch auf ihren IIS (Wenn ich das will ). Nur ich komme wieder nicht dran.
Fazit:
- gesperrt ist bestimmt nichts. Zumindest nicht auf Protokoll-Ebene. Dazu geht noch zuviel.
Du schreibst: "Um dann die Verbindung zu testen könnte man einmal temporär den Setup Port 80 auf dem WAN Interface freigeben und eine Telnet Verbindung auf den Port 80 aufbauen. Da müsstest du dann einen ASCII Reply vom Konfig Webserver des Routers zurückbekommen. Klappt das ist es wohl ziemlich sicher das ICMP echo durch ACLs geblockt wird."
Ich kann das gerne auf meinem Router machen. Hast Du icq? das könnte evtl. die Kommunikation vereinfachen. Hier schreibt man immer so viel. Und außer Dir kann hier offenbar keiner mehr helfen (ich glaub, das ist entweder viel zu schwer, um es aus der Ferne analysieren zu können, oder die Sache klingt zu unglaubwürdig - und ich mein, ganz ehrlich, wenn mir das hier jemand so darstellen würde, wie ich das hier live erlebe, ich würds nicht glauben...).
Wie gesagt, vielleicht könnten wir das ja über icq fortsetzen und wenns läuft, poste ich der Vollständigkeit halber noch die Lösung...
Was hälst Du denn davon?
Gruß,
TC
vielen Dank für Dein Posting.
Du schreibst "Wenn du von einem Router zum anderen pingst wird dieser mit an Sicherheit grenzender Wahrscheinlichkeit als Source IP-Adresse im ICMP Packet die des internen LANs nehmen und schon nimmt das Unglück seinen Lauf."
Das müßte ich doch testen können, oder? Ich glaube, mit iptraf (unter Linux) würde man sehen, wenn ich ihn anpinge, gell? Du hast nicht zufällig einen Linux-Rechner, den ich mal anpingen könnte?
Deine andere Idee gefällt mir eigentlich auch, aber auch das können wir sicherlich ausschließen:
Die Sache mit dem ICMP echo und -reply. Denn wenn er das machen würde, wieso kann ich dann alle anderen Teilnehmer seines Netzwerks anpingen? Er müßte den Filter schon auf unsere 2 IPs legen, und das hat er nicht. Der ISP-Verantworliche ist ein entfernter Verwandter, ich bin Per-Du mit ihm und kann es mir nicht vorstellen. Er hätte doch keinen Vorteil davon, denn wir haben beide recht teure Volumentarife, alles was über die Antenne geht, auch von mir zu meiner Schwester (was ihn als ISP also keinen Traffic bei der DTAG kostet), kostet Geld. Wozu sollte er diesen Umstand machen? Und noch ein Argument:
Du kommst doch auf meinen Webserver. Wieso kommt meine Schwester nicht dran? Der ISP müßte doch demnach auch Port 80 sperren. Hat er aber nicht. Meine Schwester kann auch surfen, und wenn ich ihren Port 80 auf den PC leite, kommt man auch auf ihren IIS (Wenn ich das will
). Nur ich komme wieder nicht dran.Fazit:
- gesperrt ist bestimmt nichts. Zumindest nicht auf Protokoll-Ebene. Dazu geht noch zuviel.
Du schreibst: "Um dann die Verbindung zu testen könnte man einmal temporär den Setup Port 80 auf dem WAN Interface freigeben und eine Telnet Verbindung auf den Port 80 aufbauen. Da müsstest du dann einen ASCII Reply vom Konfig Webserver des Routers zurückbekommen. Klappt das ist es wohl ziemlich sicher das ICMP echo durch ACLs geblockt wird."
Ich kann das gerne auf meinem Router machen. Hast Du icq? das könnte evtl. die Kommunikation vereinfachen. Hier schreibt man immer so viel. Und außer Dir kann hier offenbar keiner mehr helfen (ich glaub, das ist entweder viel zu schwer, um es aus der Ferne analysieren zu können, oder die Sache klingt zu unglaubwürdig - und ich mein, ganz ehrlich, wenn mir das hier jemand so darstellen würde, wie ich das hier live erlebe, ich würds nicht glauben...).
Wie gesagt, vielleicht könnten wir das ja über icq fortsetzen und wenns läuft, poste ich der Vollständigkeit halber noch die Lösung...
Was hälst Du denn davon?
Gruß,
TC
Was natürlich noch sein kann ist das deine Router auf dem WAN Interface schlicht Ping bzw. ICMP aus Sicherheitsgründen unterdrücken...
Ein Check ist recht einfach: Ins WAN Ethernet einen kleinen Hub (kein Switch !) einschleifen und einen Laptop/PC mit Ethereal (www.ethereal.com) dranhängen. Hiermit kannst du dann die Packete sehen die dort rausgehen und genau checken welche IPs die benutzen. Genau so kann man das am WLAN Port des anderen Routers machen um zu sehen was dort ankommt.
Kommen ICMP echo requests an und werden nicht beantwortet unterdrückt der Router Pings auf seiner WAN Schnittstelle.
Das Problem das deine Schwester nicht auf deinen Webserver kommt ist allerdings ungewöhnlich, wenn alle anderen aus dem großen Internet das auch können. Ggf, begrenzt dein Router ein Portforwarding auf eine Session aber das wäre ungewöhnlich. Um das aber auszuschliessen kannst du mal ein Portforwarding mit dem Port 8088 oder 8080 z.B. auf deinen Webserver zusätzlich einrichten und deine Schwester mal bitten das sie mit http://195.243.x.x:8088 mal versucht eine Verbindung mit einem "exklusiven" Port für sie zu öffnen.
Interessant wäre auch mal mit Ethereal zu sehen ob diese Packete dort überhaupt ankommen. Es ist aber erstmal unverständlich warum andere externe Verbindung bei gleicher Ausgangslage funktionieren, die aus dem LAN deiner Schwester mit gleicher Ziel IP aber nicht....
Leider habe ich kein ICQ oder andere Chat Dienste
Ein Check ist recht einfach: Ins WAN Ethernet einen kleinen Hub (kein Switch !) einschleifen und einen Laptop/PC mit Ethereal (www.ethereal.com) dranhängen. Hiermit kannst du dann die Packete sehen die dort rausgehen und genau checken welche IPs die benutzen. Genau so kann man das am WLAN Port des anderen Routers machen um zu sehen was dort ankommt.
Kommen ICMP echo requests an und werden nicht beantwortet unterdrückt der Router Pings auf seiner WAN Schnittstelle.
Das Problem das deine Schwester nicht auf deinen Webserver kommt ist allerdings ungewöhnlich, wenn alle anderen aus dem großen Internet das auch können. Ggf, begrenzt dein Router ein Portforwarding auf eine Session aber das wäre ungewöhnlich. Um das aber auszuschliessen kannst du mal ein Portforwarding mit dem Port 8088 oder 8080 z.B. auf deinen Webserver zusätzlich einrichten und deine Schwester mal bitten das sie mit http://195.243.x.x:8088 mal versucht eine Verbindung mit einem "exklusiven" Port für sie zu öffnen.
Interessant wäre auch mal mit Ethereal zu sehen ob diese Packete dort überhaupt ankommen. Es ist aber erstmal unverständlich warum andere externe Verbindung bei gleicher Ausgangslage funktionieren, die aus dem LAN deiner Schwester mit gleicher Ziel IP aber nicht....
Leider habe ich kein ICQ oder andere Chat Dienste
zu "unterdrückte Pings": das kann ich einstellen, ist auch so eingestellt, dass Pings beantwortet werden - habs auch überprüft mit ner Webseite, die Ping-Dienste zur Verfügung stellt -> Replys kommen also. Kannst ja mal pingen - die IP kennst Du ja. Allerdings, solltest Du das schon versucht haben, war's wohl ohne Erfolg, da ich nach einer Neukonfiguration letzte Woche dies übersehen habe.
zu der Idee mit dem Hub: ok, Hub, hub ich da. Laptop hab ich auch da. ethereal, sofern kostenlos, auch gleich. Sollte kein Problem sein.
zu der Idee mit den anderen Ports: Das hab ich schon versucht. Ich hab auch nebenbei die Remote-Admin-Konsole auf 8088 eingestellt (bei beiden Geräten), und hab jeweils vom gegenseitigen Netz aus versucht, an die Geräte ran zu kommen. Und das hat anfangs auch alles funktioniert.
Was meinst Du mit "gleicher Ziel IP" ??
"Interessant wäre auch mal mit Ethereal zu sehen ob diese Packete dort überhaupt ankommen. ==> JA, Sehr gute Idee. Wirklich. Das würde bedeuten, ich tausche einen der Router gegen einen PC und schaue, was passiert. Dann weiß ich schonmal, ob was ankommt.
Du schreibst: "Es ist aber erstmal unverständlich warum andere externe Verbindung bei gleicher Ausgangslage funktionieren, die aus dem LAN deiner Schwester mit gleicher Ziel IP aber nicht...." -> Genau das ist der Punkt. Verstehst Du - im Prinzip geht ja alles - Web, Remotekonsole, VPN zu mir, VNC auf ihren PC, Remote-Administration auf beide Fritzboxen werden auch reingeroutet - nur muss ich das von anderen als den PCs aus meinem Netzwerk tun. Gäbe ich Dir alle IPs, Ports und PWs, kämst Du an alles ran...
Der Router begrenzte bisher nicht. Ich hatte schon einige gleichzeitige VPN-Sessions, FTP-Uploads, Webbesucher und ne VNC-Session (also, all dies zusammen... problemlos). Demnach kann ich das ausschließen.
Es sieht ja irgendwie fast so aus, als würden die Router mir was sperren. Quatsch, vergiss es, sie können sich ja gegenseitig nicht anpingen. Also ich komm nicht drumrum, ich muss herausfinden, ob Pakete von einem Router bei dem anderen Netzwerk ankommen -> Austausch mit PC... na, das kann heiter werden...
Gruß,
TC
zu der Idee mit dem Hub: ok, Hub, hub ich da. Laptop hab ich auch da. ethereal, sofern kostenlos, auch gleich. Sollte kein Problem sein.
zu der Idee mit den anderen Ports: Das hab ich schon versucht. Ich hab auch nebenbei die Remote-Admin-Konsole auf 8088 eingestellt (bei beiden Geräten), und hab jeweils vom gegenseitigen Netz aus versucht, an die Geräte ran zu kommen. Und das hat anfangs auch alles funktioniert.
Was meinst Du mit "gleicher Ziel IP" ??
"Interessant wäre auch mal mit Ethereal zu sehen ob diese Packete dort überhaupt ankommen. ==> JA, Sehr gute Idee. Wirklich. Das würde bedeuten, ich tausche einen der Router gegen einen PC und schaue, was passiert. Dann weiß ich schonmal, ob was ankommt.
Du schreibst: "Es ist aber erstmal unverständlich warum andere externe Verbindung bei gleicher Ausgangslage funktionieren, die aus dem LAN deiner Schwester mit gleicher Ziel IP aber nicht...." -> Genau das ist der Punkt. Verstehst Du - im Prinzip geht ja alles - Web, Remotekonsole, VPN zu mir, VNC auf ihren PC, Remote-Administration auf beide Fritzboxen werden auch reingeroutet - nur muss ich das von anderen als den PCs aus meinem Netzwerk tun. Gäbe ich Dir alle IPs, Ports und PWs, kämst Du an alles ran...
Der Router begrenzte bisher nicht. Ich hatte schon einige gleichzeitige VPN-Sessions, FTP-Uploads, Webbesucher und ne VNC-Session (also, all dies zusammen... problemlos). Demnach kann ich das ausschließen.
Es sieht ja irgendwie fast so aus, als würden die Router mir was sperren. Quatsch, vergiss es, sie können sich ja gegenseitig nicht anpingen. Also ich komm nicht drumrum, ich muss herausfinden, ob Pakete von einem Router bei dem anderen Netzwerk ankommen -> Austausch mit PC... na, das kann heiter werden...
Gruß,
TC
also jetzt versteh ich garnix mehr...
mit angry ip-scanner kann ich die ip meiner schwester anpingen und bekomm sogar den dns-namen.
wie das???
mit angry ip-scanner kann ich die ip meiner schwester anpingen und bekomm sogar den dns-namen.
wie das???
Hallo,
vielen Dank für diese sehr
ausführliche Erläuterung.
Soll ich es mit einem Bild probieren?
Vielleicht vereinfacht das die Sache...
Ich versuche es nochmal, einfach zu
erklären.
Mein Provider gibt mir einen Internetzugang
mit öffentlicher IP (195.243.xx.>128
/ 255.255.255.128). Dieser Zugang sieht so
aus:
Ich muss für die RF-Strecke einen
Accesspoint haben, im Client-Mode. Dahinter
kann normalerweise ein PC, der die
öffentliche IP bekommt (über die
beim Provider registrierte MAC ist das
System vor Missbrauch geschützt).
So, nun hab ich aber nicht einen PC,
sondern 2, einen Laptop, einen Linuxserver
und eine Fritzbox. Also brauch ich 5 interne
IPs und einen Router.
In diesem Fall erhält der Router
- als WAN-Adresse die 195.243.xx.xxx /
255.255.255.128
- als Gateway die 192.168.1.1, DNS kann
ich mir aussuchen, hier ist der vom Provider
eingestellt (195.243.xx.x)
Die PCs und co. bekommen
192.168.0.x-Adressen.
vielen Dank für diese sehr
ausführliche Erläuterung.
Soll ich es mit einem Bild probieren?
Vielleicht vereinfacht das die Sache...
Ich versuche es nochmal, einfach zu
erklären.
Mein Provider gibt mir einen Internetzugang
mit öffentlicher IP (195.243.xx.>128
/ 255.255.255.128). Dieser Zugang sieht so
aus:
Ich muss für die RF-Strecke einen
Accesspoint haben, im Client-Mode. Dahinter
kann normalerweise ein PC, der die
öffentliche IP bekommt (über die
beim Provider registrierte MAC ist das
System vor Missbrauch geschützt).
So, nun hab ich aber nicht einen PC,
sondern 2, einen Laptop, einen Linuxserver
und eine Fritzbox. Also brauch ich 5 interne
IPs und einen Router.
In diesem Fall erhält der Router
- als WAN-Adresse die 195.243.xx.xxx /
255.255.255.128
- als Gateway die 192.168.1.1, DNS kann
ich mir aussuchen, hier ist der vom Provider
eingestellt (195.243.xx.x)
Die PCs und co. bekommen
192.168.0.x-Adressen.
Du machst es dir Schwerer als es ist, warst du schon einmal auf einer LAN? Hast du dort schon einmal mehere Router hintereinander gesehen? Ich noch nicht, da diese nur switcher verwenden, dennoch, ein Router funktioniert nicht anders, nur das die Pakete vorher geprüft werden die reinkommen und Rausgehen.
Schliese deinen einen router an, damit alles geht, dann schlieste deinen 2ten Router am ersten an, und verwendest den als Hub, ansonsten verkauf beide Router und hol dir einen 10ner oder 20ziger router, dann haste die Sorgen nicht, ich selber habe den Netgear RP616 Router mit 5 Ports, und sollte das nicht langen häng ich noch nen 5èr Hub dran, vergeb die internen IP`s und ruhe ist, damit hab ich schon ne 8`ter Lan bei mir zuhause gemacht und alle kamen ins Internet!
Ich sag dazu nur eins, manche Menschen machen es sich echt schwerer obwohl der einfachste weg doch der Sinnvollste ist.
Zumal würde ich niemals einen Funk Router nehmen, lieber verlege ich 100Meter lan kabel, da bin ich sicherer!
1 Router hat die Standartgateway 192.168.0.1 der PC sollte dann 192.168.0.2 haben, die Supnetmaske liegt bei 255.255.255.0, und dann die bevorzugten DNS Server nummern natürlich, alle anderen PC`s sollten dann mit der internen IP folgen xxx.xxx.x.3-50
2 Router 2 fungiert dann nur noch als Hub!, Denn nu kannst deine Internet daten nicht gleich 2mal mit den selben einstellungen einrichten, (Ich meine wohl das das nicht möglich wäre, kann mich allerdings auch Täuschen).
Somit wäre es erforderlich das du einen 2ten Anschluss von deinem Provider benötigst mit anderen Anmelde Daten, dann erst wird es funktionieren, denn dann arbeiten beide unabhängig von einander und beide können angepingt werden.
Sollte ich Falsch liegen, so höre ich gerne zu.
Aber mehrer Organisierte Lans, bestätigen dies!
Sio Kein IT Experte, nur 28Jahre PC Ehrfahrung
(PC-Freak)
Hallo samsonetty,
bei allem Verständnis und Respekt, aber ich glaube, hier hast Du einiges falsch verstanden. Aber das ist garnicht so schlimm, denn die Situation ist echt kompliziert.
Vielleicht schaust Du Dir einfach nochmal die Grafik an.
Ich hab ja garkeine andere Möglichkeit, als den Router, denn ein Switsch erlaubt mir wohl kaum, eine Verbindung mit dem Internet herzustellen, wenn es ums Routing vom privaten zum öffentlichen Netzwerk geht.
Mehrere Router hintereinander, ist wohl hier auch am Ziel vorbei. Zum Einen kann ich ja schlecht meinem ISP vorschreiben, wie er meinen PC ins Internet bringt, zum anderen hab ich den vorgeschlagenen Aufbau sowieso, auch wenn ich ihn nicht eingezeichnet hab. Hinter meinem Router liegen sogar 2 Switches, da auch Drucker mit LAN-Karten angebunden sind.
Aber das ist alles nicht das Thema.
Fakt ist:
1. beide Netzwerke sind von außen erreichbar
2. beide Netzwerke bringen alle Geräte hervorragend ins WAN
3. NUR die Verbindung von einem Router zum anderen kommt nicht ganz korrekt zustande. Hierzu gibt es aber neue Erkenntnisse, vorgestellt in einem neuen Thread.
Gruß,
TC
bei allem Verständnis und Respekt, aber ich glaube, hier hast Du einiges falsch verstanden. Aber das ist garnicht so schlimm, denn die Situation ist echt kompliziert.
Vielleicht schaust Du Dir einfach nochmal die Grafik an.
Ich hab ja garkeine andere Möglichkeit, als den Router, denn ein Switsch erlaubt mir wohl kaum, eine Verbindung mit dem Internet herzustellen, wenn es ums Routing vom privaten zum öffentlichen Netzwerk geht.
Mehrere Router hintereinander, ist wohl hier auch am Ziel vorbei. Zum Einen kann ich ja schlecht meinem ISP vorschreiben, wie er meinen PC ins Internet bringt, zum anderen hab ich den vorgeschlagenen Aufbau sowieso, auch wenn ich ihn nicht eingezeichnet hab. Hinter meinem Router liegen sogar 2 Switches, da auch Drucker mit LAN-Karten angebunden sind.
Aber das ist alles nicht das Thema.
Fakt ist:
1. beide Netzwerke sind von außen erreichbar
2. beide Netzwerke bringen alle Geräte hervorragend ins WAN
3. NUR die Verbindung von einem Router zum anderen kommt nicht ganz korrekt zustande. Hierzu gibt es aber neue Erkenntnisse, vorgestellt in einem neuen Thread.
Gruß,
TC
@Samsonetty
Switches und Router sind grundverschieden ! Da liegst du falsch mit deiner obigen Beschreibung, sorry... ! Ein normaler Switch arbeitet auf dem OSI Layer 2 also basierend auf MAC Adressen wohingegen ein Router auf dem OSI Layer 3 der Netzwerkebene (IP Adressen bzw, bei Appletalk Novell IPX etc. deren Netzadressen) arbeitet. Es gibt natürlich auch L3 Switches die haben dann auch noch einen Router integriert bzw. switchen dann auf L3.
Das verwirrende an den hier oft beschriebenen DSL Routern wie auch oben ist eigentlich das sie alles beinhalten nämlich
a: einen Router der Das Routing zwischen DSL und LAN macht
b: einen meist 4 port Switch der dafür sorgt das man nicht nur einen einzelnen Ethernet Port hat
c: Einen wireless Access Pont der im Bridge (Layer 2) Modus zwischen LAN und WLAN arbeitet
Alles 3 bzw. die Kombination auf einem Gerät sorgt hier im Forum aber des öfteren für Verwirrungen und falsche Beschreibungen und hat dich sicher auch etwas aufs Glatteis geführt...
Switches und Router sind grundverschieden ! Da liegst du falsch mit deiner obigen Beschreibung, sorry... ! Ein normaler Switch arbeitet auf dem OSI Layer 2 also basierend auf MAC Adressen wohingegen ein Router auf dem OSI Layer 3 der Netzwerkebene (IP Adressen bzw, bei Appletalk Novell IPX etc. deren Netzadressen) arbeitet. Es gibt natürlich auch L3 Switches die haben dann auch noch einen Router integriert bzw. switchen dann auf L3.
Das verwirrende an den hier oft beschriebenen DSL Routern wie auch oben ist eigentlich das sie alles beinhalten nämlich
a: einen Router der Das Routing zwischen DSL und LAN macht
b: einen meist 4 port Switch der dafür sorgt das man nicht nur einen einzelnen Ethernet Port hat
c: Einen wireless Access Pont der im Bridge (Layer 2) Modus zwischen LAN und WLAN arbeitet
Alles 3 bzw. die Kombination auf einem Gerät sorgt hier im Forum aber des öfteren für Verwirrungen und falsche Beschreibungen und hat dich sicher auch etwas aufs Glatteis geführt...
LOl danke für die Aufklärung, ich bin halt jemand der versucht es einem Laien so unkompleziert und un lateinisch zu übersetzen, auch wenn ich jetzt falsch lag, lag ich doch in der richtung ein wenig richtig.
Man sollte halt gleich in die Frage setzten das man
a. einen DSL Router oder
b. einen WLAN Router hat, damit sind dann eigentlich schon die Grundfragen beantwortet.
sio Sam
Man sollte halt gleich in die Frage setzten das man
a. einen DSL Router oder
b. einen WLAN Router hat, damit sind dann eigentlich schon die Grundfragen beantwortet.
sio Sam
hallo Sam,
ich denke, das ging aus der Sache ansich hervor. Ich hab noch keinen Richtfunk-DSL-Zugang gesehn und kann mir nicht vorstellen, dass dies technisch ohne weiteres lösbar wäre.
Nicht, dass es jetzt dramatisch wäre, aber es war von Anfang an die Ausgangssituation eigentlich klar definiert.
Des Weiteren steht ja auch eine Grafik zur Verfügung, die die komplette Situation verdeutlicht. Von DSL war nie die Rede.
Aber ich bin Dir dankbar, dass Du versucht hast zu helfen. Manchmal muss man auch falsch liegen, um Ideen zu entwickeln, die einen in anderen Situationen helfen.
Vielleicht hast Du ja jetzt, nachdem Du die Konfig besser kennst, eine andere Idee, ich tappe nämlich immernoch im Dunkeln.
Gruß an alle,
TC
ich denke, das ging aus der Sache ansich hervor. Ich hab noch keinen Richtfunk-DSL-Zugang gesehn und kann mir nicht vorstellen, dass dies technisch ohne weiteres lösbar wäre.
Hallo,
folgende Konfiguration:
Es gibt 2 Netzwerke, jedes hinter einem Router (Linksys WRT54 GC) "versteckt".
Beide Netzwerke sind beim gleichen Provider, jedes mit einer festen IP über Richtfunk angebunden.
folgende Konfiguration:
Es gibt 2 Netzwerke, jedes hinter einem Router (Linksys WRT54 GC) "versteckt".
Beide Netzwerke sind beim gleichen Provider, jedes mit einer festen IP über Richtfunk angebunden.
Nicht, dass es jetzt dramatisch wäre, aber es war von Anfang an die Ausgangssituation eigentlich klar definiert.
Des Weiteren steht ja auch eine Grafik zur Verfügung, die die komplette Situation verdeutlicht. Von DSL war nie die Rede.
Aber ich bin Dir dankbar, dass Du versucht hast zu helfen. Manchmal muss man auch falsch liegen, um Ideen zu entwickeln, die einen in anderen Situationen helfen.
Vielleicht hast Du ja jetzt, nachdem Du die Konfig besser kennst, eine andere Idee, ich tappe nämlich immernoch im Dunkeln.
Gruß an alle,
TC
