15187
May 01, 2006, updated at May 03, 2006 at 13:21:34 (UTC)
5185
4
0
2 Netzwerke verbinden funktioniert nicht - Teil 2
hier ein anderer Ansatz zur Fehlerbehebung
Also, ich glaube, dieses phänomenale Verhalten ist ein Thread für die Königsklasse der IP-Spezialisten
Problem: 2 Kunden beim gleichen ISP, ausgestattet mit fester IP können sich gegenseitig nicht anpingen und auch keine gegenseitigen Dienste in Anspruch nehmen. Alles ist aber korrekt konfiguriert und funktioniert für Außenstehende.
Aqui hat in zu diesem Thema schon sehr viel Unterstützung geleistet, aber wir kamen dem Problem noch nicht auf die Spur.
Hier und heute eine gravierende Erkenntnis:
- auf Pings von meinem zu dem gegnerischen Router bekomme ich Zeitüberschreitung
- Tracerouting stoppt schon bei meiner öffentlichen IP -> ich werd also nicht weitergeleitet?!
- in die Gegenrichtung exakt das gleiche Verhalten
- beide Kunden haben eine IP größer als 128, mit der Subnet 255.255.255.128
- JETZT NEU: mit dem Programm "Angry IP Scanner" scanne ich das Netz von der IP 1 bis zur 254 durch, und siehe da: ich bekomme vom gegnerischen Router ein Reply, und sogar seinen DNS. Ab jetzt kann ich auch vom PC aus pingen und komme sogar an die Dienste, die ich per Portforwarding reinroute.
Dieser glückliche Zustand erlischt nach wenigen Minuten, dann "sterben" die Verbindungen wieder.
Hat irgendjemand eine Idee, woher dieses Verhalten kommen kann? Ist der Angry-IP-Scanner ein Allheilmittel gegen Verbindungsschwächen, oder stellt es gar Verbindungen her, die nicht möglich sind? Fragen über Fragen, und ich zweifle an meinem Verstand für IP-Netze...
Ich hab allerdings einen -vielleicht auch unbegründeten- Verdacht, dass das Subnet .128 etwas damit zu tun haben könnte. Mein Provider bestreitet ja so ziemlich alle Verdachtsfragen auf seine Netzwerkstruktur. Seiner Meinung nach müsse es einfach gehen. Ich hatte schon die Windows-Firewall im Verdacht, aber von Router zu Router gings ja auch schon nicht (wer Zeit hat und die gesamte Story lesen will; ).
weiterhin Merkwürdig: Andere IPs im Segment oberhalb der 128 kann ich jederzeit pingen (sofern nicht Firewalls blocken oder User offline sind).
Ok, stimmt seit wenigen Minuten auch nicht mehr, denn: Ich versuche seit einiger Zeit, mit dem AIS dieses Massenpingen, ich erreiche unterhalb der 128 alle Server meines Providers, oberhalb nur noch die 128 und meine eigene externe IP.
Jetzt versteh ich garnix mehr. Vor 15 Minuten ging das noch...
Problem: 2 Kunden beim gleichen ISP, ausgestattet mit fester IP können sich gegenseitig nicht anpingen und auch keine gegenseitigen Dienste in Anspruch nehmen. Alles ist aber korrekt konfiguriert und funktioniert für Außenstehende.
Aqui hat in zu diesem Thema schon sehr viel Unterstützung geleistet, aber wir kamen dem Problem noch nicht auf die Spur.
Hier und heute eine gravierende Erkenntnis:
- auf Pings von meinem zu dem gegnerischen Router bekomme ich Zeitüberschreitung
- Tracerouting stoppt schon bei meiner öffentlichen IP -> ich werd also nicht weitergeleitet?!
- in die Gegenrichtung exakt das gleiche Verhalten
- beide Kunden haben eine IP größer als 128, mit der Subnet 255.255.255.128
- JETZT NEU: mit dem Programm "Angry IP Scanner" scanne ich das Netz von der IP 1 bis zur 254 durch, und siehe da: ich bekomme vom gegnerischen Router ein Reply, und sogar seinen DNS. Ab jetzt kann ich auch vom PC aus pingen und komme sogar an die Dienste, die ich per Portforwarding reinroute.
Dieser glückliche Zustand erlischt nach wenigen Minuten, dann "sterben" die Verbindungen wieder.
Hat irgendjemand eine Idee, woher dieses Verhalten kommen kann? Ist der Angry-IP-Scanner ein Allheilmittel gegen Verbindungsschwächen, oder stellt es gar Verbindungen her, die nicht möglich sind? Fragen über Fragen, und ich zweifle an meinem Verstand für IP-Netze...
Ich hab allerdings einen -vielleicht auch unbegründeten- Verdacht, dass das Subnet .128 etwas damit zu tun haben könnte. Mein Provider bestreitet ja so ziemlich alle Verdachtsfragen auf seine Netzwerkstruktur. Seiner Meinung nach müsse es einfach gehen. Ich hatte schon die Windows-Firewall im Verdacht, aber von Router zu Router gings ja auch schon nicht (wer Zeit hat und die gesamte Story lesen will; ).
weiterhin Merkwürdig: Andere IPs im Segment oberhalb der 128 kann ich jederzeit pingen (sofern nicht Firewalls blocken oder User offline sind).
Ok, stimmt seit wenigen Minuten auch nicht mehr, denn: Ich versuche seit einiger Zeit, mit dem AIS dieses Massenpingen, ich erreiche unterhalb der 128 alle Server meines Providers, oberhalb nur noch die 128 und meine eigene externe IP.
Jetzt versteh ich garnix mehr. Vor 15 Minuten ging das noch...
Please also mark the comments that contributed to the solution of the article
Content-Key: 31518
Url: https://administrator.de/contentid/31518
Printed on: April 26, 2024 at 21:04 o'clock
4 Comments
Latest comment
Scheint wirklich für die Königsklasse zu sein....
2 Dinge stimmen mich stutzig.... Die 128er Subnetzmaske ist schon sehr ungewöhnlich für ein Zugangsnetz vom Carrier. Das bedeutet das dort in dem Segment nur max. 126 andere Kunden sich befinden können. Eigentlich recht wenig und ungewöhnlich es sei denn aus Bandbreitengesichtspunkten lässt er nicht mehr zu, da die sich meist einen drahtlosen Zugangspunkt teilen. Mag sein das er alle Funkzellen nur mit max. 128 Kunden ausrüstet. Rein vom Verständnis müsstest du alle Endgeräte die im Subnetz deines Routers sind auch erreichen können, da die ja nur Layer 2 seitig verbunden sind (gleiches Subnetz).
Ohne die genaue Kenntnis der Carrierstruktur ist aber eine genaue Hilfe unmöglich. Vielleicht rückt er deshalb so spärlich mit Infos raus
Es kann aber sein das dein Carrier alle Funkschnittstellen auf einem Switch in einem private VLAN kumuliert, das erlaubt dann keine ARP Broadcasts zu den Endgeräteports und man kann nur über einen zentralen Uplink Port kommunizieren.....das ist aber alles Spekulation.
Nach deinen Traceroute Erfahrungen, sieht es aber so aus als ob der Carrier ICMP Packete komplett oder in Teilen filtert, wahrscheinlich aus Security Gründen. Das Verhalten spricht jedenfalls dafür.
Wie gesagt ich würde an die WAN Ports der Router Sniffer wie Ethereal hängen und würde mal sehen welcher Art Packete überhaupt an die Router durchkommen. Wenn du z.B. Telnet Requests (Port 23) auf die Router losschickst sollten die eigentlich ankommen. TCP Packete werden meist nicht gefiltert. Zeitgesteuerte Accesslisten sind bei Carriern eigentlich recht selten (wer sollte die administrieren..) geschweige denn ACL die bei einem Port SCanning aufmachen und nach einer zeit wieder zu....das gehört m.E. ins Reich der Märchen.
2 Dinge stimmen mich stutzig.... Die 128er Subnetzmaske ist schon sehr ungewöhnlich für ein Zugangsnetz vom Carrier. Das bedeutet das dort in dem Segment nur max. 126 andere Kunden sich befinden können. Eigentlich recht wenig und ungewöhnlich es sei denn aus Bandbreitengesichtspunkten lässt er nicht mehr zu, da die sich meist einen drahtlosen Zugangspunkt teilen. Mag sein das er alle Funkzellen nur mit max. 128 Kunden ausrüstet. Rein vom Verständnis müsstest du alle Endgeräte die im Subnetz deines Routers sind auch erreichen können, da die ja nur Layer 2 seitig verbunden sind (gleiches Subnetz).
Ohne die genaue Kenntnis der Carrierstruktur ist aber eine genaue Hilfe unmöglich. Vielleicht rückt er deshalb so spärlich mit Infos raus
Es kann aber sein das dein Carrier alle Funkschnittstellen auf einem Switch in einem private VLAN kumuliert, das erlaubt dann keine ARP Broadcasts zu den Endgeräteports und man kann nur über einen zentralen Uplink Port kommunizieren.....das ist aber alles Spekulation.
Nach deinen Traceroute Erfahrungen, sieht es aber so aus als ob der Carrier ICMP Packete komplett oder in Teilen filtert, wahrscheinlich aus Security Gründen. Das Verhalten spricht jedenfalls dafür.
Wie gesagt ich würde an die WAN Ports der Router Sniffer wie Ethereal hängen und würde mal sehen welcher Art Packete überhaupt an die Router durchkommen. Wenn du z.B. Telnet Requests (Port 23) auf die Router losschickst sollten die eigentlich ankommen. TCP Packete werden meist nicht gefiltert. Zeitgesteuerte Accesslisten sind bei Carriern eigentlich recht selten (wer sollte die administrieren..) geschweige denn ACL die bei einem Port SCanning aufmachen und nach einer zeit wieder zu....das gehört m.E. ins Reich der Märchen.
Mmmhhh, das ist schon ein höchst sonderbares Verhalten...wenigstens nicht normal bzw. standardkonform. Es gibt noch weitere Ursachen was es sein könnte, wie z.B. ein ARP Cache der nicht aktualisiert wird und nach der Timeoutzeit gelöscht wird. Der Carrier könnte mit Proxy ARP auf dem Router arbeiten....aber all das passt dann nicht mit dem Verhalten zusammen das es zeitweise funktioniert.
Wahrscheinlich liest er mit und feixt sich einen wie wir hier philosophieren.... Spaß beiseite, es ist und bleibt "Shooting in the dark" nach dem Warum soweit wir seine Infrastruktur nicht besser kennen. Alles in diesem Forum zu diskutieren warum es eigentlich gehen sollte sprengt den Rahmen...davon könnte man dann ein Buch drucken
Wahrscheinlich liest er mit und feixt sich einen wie wir hier philosophieren.... Spaß beiseite, es ist und bleibt "Shooting in the dark" nach dem Warum soweit wir seine Infrastruktur nicht besser kennen. Alles in diesem Forum zu diskutieren warum es eigentlich gehen sollte sprengt den Rahmen...davon könnte man dann ein Buch drucken