non-expert
Goto Top

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?!

Content-Key: 665966

Url: https://administrator.de/contentid/665966

Ausgedruckt am: 29.03.2024 um 07:03 Uhr

Mitglied: it-fraggle
it-fraggle 21.04.2021 um 11:48:24 Uhr
Goto Top
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?
Mitglied: non-expert
non-expert 21.04.2021 um 12:14:44 Uhr
Goto Top
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,
Mitglied: aqui
aqui 21.04.2021 aktualisiert um 12:27:45 Uhr
Goto Top
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.
Diese 2 Winblows Firewall Allerwelts Regeln hattest du vermutlich nicht auf dem Radar...?!
Mitglied: non-expert
non-expert 21.04.2021 aktualisiert um 12:42:39 Uhr
Goto Top
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.
Mitglied: NordicMike
NordicMike 21.04.2021 um 14:32:38 Uhr
Goto Top
Mach mal ein Trace und TCPdump, dann siehst du wie weit es kommt bzw ob der Rückweg evtl daran schuld ist.
Mitglied: non-expert
non-expert 21.04.2021, aktualisiert am 22.04.2021 um 10:51:15 Uhr
Goto Top
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.
Mitglied: NordicMike
NordicMike 22.04.2021 um 11:29:17 Uhr
Goto Top
auf Laptop 192.168.x.3
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.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.
Mitglied: non-expert
non-expert 27.04.2021 aktualisiert um 10:38:40 Uhr
Goto Top
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.
Mitglied: aqui
aqui 27.04.2021 aktualisiert um 11:26:34 Uhr
Goto Top
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 ! face-wink
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
Mitglied: non-expert
non-expert 27.04.2021 um 13:43:48 Uhr
Goto Top
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.
Mitglied: aqui
aqui 27.04.2021 aktualisiert um 14:35:56 Uhr
Goto Top
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 ??
Mitglied: non-expert
non-expert 27.04.2021 um 15:52:16 Uhr
Goto Top
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...
Mitglied: non-expert
non-expert 29.04.2021 um 08:49:25 Uhr
Goto Top
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.
Mitglied: NordicMike
NordicMike 29.04.2021 um 09:51:19 Uhr
Goto Top
Danke für die Statusmeldung.

Hast du die Routen dess VPN Tunnels notiert?
Beissen sich die IP Adressen?
Mitglied: non-expert
non-expert 29.04.2021 aktualisiert um 10:41:22 Uhr
Goto Top
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!