15
IP Adresse blockiert? kein Ping auf Terminalserver
Hallo an alle Fachleute!
Nach Jahren habe ich scheinbar wieder einmal ein Problem konstruiert, für das ich auf gute Hinweise hoffe.
Die Konstellation funktionierte jahrelang, ohne bewusste Änderungen nun nicht mehr.
Konstellation:
eigenes Laptop 192.168.y.3
Netzwerk Zentrale 192.168.x.0, statisch, MSServer2019
Netzwerk Niederlassung 192.168.y.0, statisch
Beide über VPN (Router-Router) verbunden, Bridge funktioniert:
Im Netz 192.168.y.0 kann ich alle Geräte mit ping <= 1 ms erreichen. Die PC im Netz 192.168.y.0 erreichen alle Geräte in 192.168.y.0 und im Netz 192.168.x.0. (z.B. 192.168.y.4 kann auch 192.168.y.3 anpingen)
Mein Laptop: Im Netz 192.168.x.0 kann ich fast alle Geräte mit ping ~ 37 ms erreichen. Den DC 192.168.y.1 zum Beispiel erreiche ich, den TS 192.168.y.2 aber nicht (Zeitüberschreitung der Anforderung).
Bisherige Überlegungen ohne Erfolg:
- gewürdigt: http://www.cycotec.de/index.php/netzwerk/allgemein/49-der-ping-befehl-u ...
- Firewall DC, TS, Laptop geprüft, Ping ist zugelassen.
- Adapter (Ethernet/Wi-Fi) abwechselnd deaktiviert, IP-Adressen testweise geändert
- Netzwerkkabel getauscht
- Switch getauscht
- Laptop gewechselt und alles vorige nochmal gemacht
Ich ahne nicht einmal mehr, woran es liegen kann?!
Nach Jahren habe ich scheinbar wieder einmal ein Problem konstruiert, für das ich auf gute Hinweise hoffe.
Die Konstellation funktionierte jahrelang, ohne bewusste Änderungen nun nicht mehr.
Konstellation:
eigenes Laptop 192.168.y.3
Netzwerk Zentrale 192.168.x.0, statisch, MSServer2019
Netzwerk Niederlassung 192.168.y.0, statisch
Beide über VPN (Router-Router) verbunden, Bridge funktioniert:
Im Netz 192.168.y.0 kann ich alle Geräte mit ping <= 1 ms erreichen. Die PC im Netz 192.168.y.0 erreichen alle Geräte in 192.168.y.0 und im Netz 192.168.x.0. (z.B. 192.168.y.4 kann auch 192.168.y.3 anpingen)
Mein Laptop: Im Netz 192.168.x.0 kann ich fast alle Geräte mit ping ~ 37 ms erreichen. Den DC 192.168.y.1 zum Beispiel erreiche ich, den TS 192.168.y.2 aber nicht (Zeitüberschreitung der Anforderung).
Bisherige Überlegungen ohne Erfolg:
- gewürdigt: http://www.cycotec.de/index.php/netzwerk/allgemein/49-der-ping-befehl-u ...
- Firewall DC, TS, Laptop geprüft, Ping ist zugelassen.
- Adapter (Ethernet/Wi-Fi) abwechselnd deaktiviert, IP-Adressen testweise geändert
- Netzwerkkabel getauscht
- Switch getauscht
- Laptop gewechselt und alles vorige nochmal gemacht
Ich ahne nicht einmal mehr, woran es liegen kann?!
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: 665966
Url: https://administrator.de/contentid/665966
Ausgedruckt am: 25.11.2024 um 03:11 Uhr
15 Kommentare
Neuester Kommentar
1. In den Firewalls prüfen, ob ICMP Echo Requests durch gehen. Und zwar Alle FWs nacheinander.
2. Auf dem Server in der Ereignisanzeige auf ID 2005 prüfen, ob die Pings überhaupt dort ankommen.
3. Lässt sich überhaupt der Server von einem Gerät im gleichen Netzwerk anpingen/erreichen? Was steht in der Arp-Tabelle? Dabei?
2. Auf dem Server in der Ereignisanzeige auf ID 2005 prüfen, ob die Pings überhaupt dort ankommen.
3. Lässt sich überhaupt der Server von einem Gerät im gleichen Netzwerk anpingen/erreichen? Was steht in der Arp-Tabelle? Dabei?
zu 1.: von anderen Rechnern kein Problem, nur von den Laptops auf den TS, eine spezielle Regel für den TS existiert nicht, die Firewalls haben sämtlich die Daei- und Druckerfreigabe (Echoanforderung) zugelassen.
zu 2.: von anderen Rechnern kein Problem, der physisch gleiche DC 192.168.y.1 wird erreicht, der virtuelle TS nicht. Andere Rechner haben kein Problem den TS zu erreichen. Im Netz 192.168.x.0 gibt es auch keine Probleme.
zu 3.: der Server lässt sich von allen anderen PC der beiden Netze aus anpingen. In der ARP Tabelle steht auch der TS mit seiner physischen Adresse,
zu 2.: von anderen Rechnern kein Problem, der physisch gleiche DC 192.168.y.1 wird erreicht, der virtuelle TS nicht. Andere Rechner haben kein Problem den TS zu erreichen. Im Netz 192.168.x.0 gibt es auch keine Probleme.
zu 3.: der Server lässt sich von allen anderen PC der beiden Netze aus anpingen. In der ARP Tabelle steht auch der TS mit seiner physischen Adresse,
Beide über VPN (Router-Router) verbunden, Bridge funktioniert:
Bridging ist Quatsch, denn da es 2 unterschiedliche IP Netze sind routen die VPN Router. Niemals bridgen sie. Aber egal...Den DC 192.168.y.1 zum Beispiel erreiche ich, den TS 192.168.y.2 aber nicht
Das hat bei Windows Geräten immer 2 Gründe:- Die lokale Windows Firewall blockiert per Default immer jeglichen ICMP Traffic (Ping). Siehe dazu auch HIER. Man muss ICMP also immer erst explizit erlauben !!
- Per Default blockt die Windows Firewall auch Pakete die fremde Absender IPs haben die nicht aus dem lokalen Netz kommen. Auch das muss man immer customizen.
a) danke für die Vokabel, die Route 192.168.x.0 zu 192.168.y.0 ist stabil.
b.1) ist erlaubt
b.2) ist erlaubt
wegen b.1 und b.2 funktioniert es ja von allen anderen Rechnern und bisher auch vom Laptop.
b.1) ist erlaubt
b.2) ist erlaubt
wegen b.1 und b.2 funktioniert es ja von allen anderen Rechnern und bisher auch vom Laptop.
Mach mal ein Trace und TCPdump, dann siehst du wie weit es kommt bzw ob der Rückweg evtl daran schuld ist.
auf Laptop 192.168.x.3
tracert 192.168.x.1 geht über Router in x, dann über Router in y, dann auf den DC
tracert 192.168.x.2 geht über Router in x, dann über Router in y, dann Zeitüberschreitung der Anforderung.
auf gerade neu installiertem PC 192.168.x.5
tracert 192.168.x.1 geht über Router in x, dann über Router in y, dann auf den DC
tracert 192.168.x.2 geht über Router in x, dann über Router in y, dann auf TS
...kann ja nur ein [WindowsUpdate-] Gerätekonflikt Ethernet/WiFi sein, wenn ich die PC ohne weiteres ins Netz bekomme, aber auch die Gateways der Laptop Adapter habe ich geprüft bzw mal den einen, mal den anderen Deaktiviert...
Update 22.4.2021: Das gleiche Problem besteht bei den Laptops (Windows10) im Homeoffice: Verbindung via VPN auf Router im Netz 192.168.y.0 funktioniert, ping auf DC funktioniert, ping auf TS "Zeitüberschreitung der Anforderung". Ein Mitarbeiter hat einen alten Windows7 Laptop. Der kann sich verbinden.
tracert 192.168.x.1 geht über Router in x, dann über Router in y, dann auf den DC
tracert 192.168.x.2 geht über Router in x, dann über Router in y, dann Zeitüberschreitung der Anforderung.
auf gerade neu installiertem PC 192.168.x.5
tracert 192.168.x.1 geht über Router in x, dann über Router in y, dann auf den DC
tracert 192.168.x.2 geht über Router in x, dann über Router in y, dann auf TS
...kann ja nur ein [WindowsUpdate-] Gerätekonflikt Ethernet/WiFi sein, wenn ich die PC ohne weiteres ins Netz bekomme, aber auch die Gateways der Laptop Adapter habe ich geprüft bzw mal den einen, mal den anderen Deaktiviert...
Update 22.4.2021: Das gleiche Problem besteht bei den Laptops (Windows10) im Homeoffice: Verbindung via VPN auf Router im Netz 192.168.y.0 funktioniert, ping auf DC funktioniert, ping auf TS "Zeitüberschreitung der Anforderung". Ein Mitarbeiter hat einen alten Windows7 Laptop. Der kann sich verbinden.
auf Laptop 192.168.x.3
Sehr merktwürdig, dass jemand im gleichen Netz aber durch kommt.
Jetzt brauchst du einen TCPdump auf Router y, der schaut, ob der Befehl aus Router y raus geht und einen TCPdump (bei WIndows Rechnern einen Wireshark), der auf dem TS schaut ob der Befehl rein kommt und auch beantwortet wird, und die ganze Beantwortungskette auch zurück geht.
tracert 192.168.x.2 geht über Router in x, dann über Router in y, dann Zeitüberschreitung der Anforderung.
auf gerade neu installiertem PC 192.168.x.5tracert 192.168.x.2 geht über Router in x, dann über Router in y, dann auf TS
Sehr merktwürdig, dass jemand im gleichen Netz aber durch kommt.
Jetzt brauchst du einen TCPdump auf Router y, der schaut, ob der Befehl aus Router y raus geht und einen TCPdump (bei WIndows Rechnern einen Wireshark), der auf dem TS schaut ob der Befehl rein kommt und auch beantwortet wird, und die ganze Beantwortungskette auch zurück geht.
Echo aufs Ping request: no response found
Schon interessant, dass der Server, auf dem wireshark läuft, ein ping an sich erkennt und "no response found" protokolliert.
pathping 192.168.y.2
Routenverfolgung zu "192.168.y.2" über maximal 30 Hops
0 DESKTOP3 [192.168.x.3]
1 router1 [192.168.x.254]
2 192.168.y.254
3 * * *
Berechnung der Statistiken dauert ca. 50 Sekunden...
Quelle zum Abs. Knoten/Verbindung
Abs. Zeit Verl./Ges.= % Verl./Ges.= % Adresse
0 DESKTOP3 [192.168.x.3]
0/ 100 = 0% |
1 0ms 0/ 100 = 0% 0/ 100 = 0% ROUTER1 [192.168.x.254]
0/ 100 = 0% |
2 36ms 0/ 100 = 0% 0/ 100 = 0% 192.168.y.254 {ROUTER2}
Ablaufverfolgung beendet.
Schon interessant, dass der Server, auf dem wireshark läuft, ein ping an sich erkennt und "no response found" protokolliert.
pathping 192.168.y.2
Routenverfolgung zu "192.168.y.2" über maximal 30 Hops
0 DESKTOP3 [192.168.x.3]
1 router1 [192.168.x.254]
2 192.168.y.254
3 * * *
Berechnung der Statistiken dauert ca. 50 Sekunden...
Quelle zum Abs. Knoten/Verbindung
Abs. Zeit Verl./Ges.= % Verl./Ges.= % Adresse
0 DESKTOP3 [192.168.x.3]
0/ 100 = 0% |
1 0ms 0/ 100 = 0% 0/ 100 = 0% ROUTER1 [192.168.x.254]
0/ 100 = 0% |
2 36ms 0/ 100 = 0% 0/ 100 = 0% 192.168.y.254 {ROUTER2}
Ablaufverfolgung beendet.
Schon interessant, dass der Server, auf dem wireshark läuft, ein ping an sich erkennt und "no response found" protokolliert.
Zeigt das seine lokale Winblows Firewall funktioniert ! 
Beim Pathping ist der Router 192.168.y.254 das Problemkind. Von dort geht es nicht weiter ins Zielnetz. Dort fehlt sehr wahrscheinlich die Route ins Zielnetz.
Hilfreich ist aber immer den -n Paramater bei Traceroute oder Pathping zu verwenden, denn das deaktiviert die DNS Namensauflösung und eliminiert damit Wartezeiten und Timeouts die nicht Routing- sondern DNS bedingt sind !!
https://en.wikipedia.org/wiki/PathPing
Wie bereits beschrieben tritt das Problem nichts systematisch, sondern nur von einzelnen Rechnern auf. Die Route vom Subnetz 192.168.x.0 ist am Lancom Router 192.168.y.254 aktiviert. Dass am Router 192.168.y.254 eine Route ins gleiche Netz 192.168.y.0 erzeugt werden müsste, macht m.E. keinen Sinn.
macht m.E. keinen Sinn.
Das ist klar und in der Tat sinnfrei denn das IP Netz ist ja direkt angeschlossen, braucht also keine Route. Das bezog sich auch eher auf das VPN IP Netz.Wenn es auch nur rein Client bezogen passiert ist es auch keinesfalls die Infrastruktur selber sondern zu 98% immer das Setup auf den Clients. Bedeutet das die VPN Route falsch, oder fehlerhaft injiziert wird am Client.
Passiert das unabhängig von irgendwelchen Betriebssystemen ??
Zuletzt haben alle clients Win10pro.
Es keimt ein neuer Verdacht: Für einen Großkunden wurde auf dem TS ein geschützter VPN-Tunnel eingerichtet (Zugriff: eigenes Netz 192.168.y.0 via VPN auf das Netz des Kunden). Den habe ich jetzt erst einmal deinstalliert samt virtuellen Adapter. Heute Nacht werden die Server neu gestartet, danach kommt alles weitere...
Es keimt ein neuer Verdacht: Für einen Großkunden wurde auf dem TS ein geschützter VPN-Tunnel eingerichtet (Zugriff: eigenes Netz 192.168.y.0 via VPN auf das Netz des Kunden). Den habe ich jetzt erst einmal deinstalliert samt virtuellen Adapter. Heute Nacht werden die Server neu gestartet, danach kommt alles weitere...
LÖSUNG: Die IT-Abteilung des Kunden hat einen VPN Tunnel auf einem PC im Netz installiert. Nach Deinstallation aller Komponenten des SonicWall VPN Tunnels und Neustart der Server arbeiten die PC wieder zuverlässig.
Danke für die Statusmeldung.
Hast du die Routen dess VPN Tunnels notiert?
Beissen sich die IP Adressen?
Hast du die Routen dess VPN Tunnels notiert?
Beissen sich die IP Adressen?
Danke für Deine Unterstützungsversuche und Dein Interesse!
Ich habe die Routen und mögliche IP-Adresskonflikte nicht dokumentiert. Mit arp hatte ich keine Adresszuordnung finden können, die den Tunnel betreffen könnte. Typisch für einen Fehler scheint mir Folgendes: Für den virtuellen Adapter war zwar "statisch" ausgewählt aber keine IP-Zuordnung getroffen, was man - manuell eingerichtet - zum Glück gar nicht abspeichern kann.
Wie dieser Zustand erzeugt wurde ? Keine Ahnung!
Ich habe die Routen und mögliche IP-Adresskonflikte nicht dokumentiert. Mit arp hatte ich keine Adresszuordnung finden können, die den Tunnel betreffen könnte. Typisch für einen Fehler scheint mir Folgendes: Für den virtuellen Adapter war zwar "statisch" ausgewählt aber keine IP-Zuordnung getroffen, was man - manuell eingerichtet - zum Glück gar nicht abspeichern kann.
Wie dieser Zustand erzeugt wurde ? Keine Ahnung!
1
