Lokales Netz nicht erreichbar bei verbundenem VPN? Vier Prüfungen

Der Tunnel kommt hoch, das Intranet erscheint, und der Drucker antwortet nicht mehr. Im LAN ist nichts ausgefallen; der Client hat den Weg geändert, den er für Adressen nutzt, die er nicht mehr als lokal behandelt. Gehen Sie die vier Prüfungen unten in der Reihenfolge durch und halten Sie an, sobald eine eine konkrete Abweichung zeigt, denn dasselbe Symptom hat vier häufige Ursachen, und nur eine davon wird durch Bearbeiten des VPN behoben.

Erstens: Sehen Sie sich die Routing-Tabelle an, die der Client installiert hat

Öffnen Sie die Routing-Tabelle des Clients, während das VPN verbunden ist. Unter Linux nutzen Sie ip route, unter Windows route print oder Get-NetRoute und unter macOS netstat -rn. Sie suchen eine Standardroute durch den Tunnel und wollen wissen, was mit der physischen Standardroute passiert ist.

Ein Full-Tunnel-Client fügt oft zwei halbe Standardrouten hinzu, 0.0.0.0/1 und 128.0.0.0/1, statt 0.0.0.0/0 zu ersetzen. Die ursprüngliche Standardroute bleibt sichtbar, verliert aber jede Suche, weshalb die Tabelle intakt aussehen kann, während der gesamte Verkehr außerhalb des Subnetzes umgeleitet wird. Bietet der VPN-Client eine Split-Tunnel-Option an und erlaubt es die Richtlinie, ist das die sauberste Reparatur.

Muss der Tunnel die Standardroute bleiben, binden Sie stattdessen das lokale Subnetz fest. Unter Linux nennt die Route die physische Schnittstelle und das Gateway; unter Windows fügen Sie -p hinzu, damit sie dauerhaft ist, und lesen die Schnittstellennummer aus route print, statt sie zu raten:

sudo ip route add 192.168.1.0/24 via 192.168.1.1 dev wlan0
route add -p 192.168.1.0 MASK 255.255.255.0 192.168.1.1 METRIC 1 IF 12

Eine fest gebundene Route hält nur, solange die Adresse, die sie nennt, gleich bleibt. Ein Laptop, der seinen WLAN-Adapter bei jeder Verbindung neu nummeriert, bricht die Regel erneut, prüfen Sie also die Schnittstellenadresse, bevor Sie entscheiden, dass die Reparatur gescheitert ist.

Zweitens: Bestätigen Sie, dass die Adresse von Anfang an lokal war

Liegt das Ziel im verbundenen Subnetz, greift die Standardroute des Tunnels nie und das VPN ist nicht die Ursache. Ein Drucker auf 192.168.1.40 bei einem Client mit 192.168.1.0/24 nutzt die verbundene Route; schlägt diese Adresse fehl, schauen Sie auf das Gerät, den Switch oder die Firewall am Client statt auf das VPN.

Der Fall, der Leute täuscht, ist eine öffentliche Adresse für einen lokalen Server. Aus dem LAN heraus erfordert das Erreichen der WAN-Adresse des Routers und die Rückkehr Hairpin-NAT, und viele Router implementieren es für Portweiterleitungen einfach nicht. Testen Sie die private Adresse neben der öffentlichen. Funktioniert die private Adresse und die öffentliche nicht, hat das VPN nur eine NAT-Einschränkung offengelegt, die schon vorher da war.

Ein Hostname verschlimmert das. Löst der lokale Name jetzt auf die öffentliche Adresse auf, versucht der Client weiter den Weg, der nicht zurückschleifen kann. Nutzen Sie die private Adresse für den Test und korrigieren Sie dann den Namen, statt eine weitere Portweiterleitung hinzuzufügen.

Drittens: Sehen Sie nach, wer jetzt Namen beantwortet

Ein Unternehmens-Resolver kennt das Intranet und weiß meist nichts über einen NAS-Hostnamen, den Bonjour-Namen eines Druckers oder den lokalen Alias eines Routers. Wenn das VPN seine DNS-Server durchsetzt, werden diese Namen nicht mehr aufgelöst, obwohl ihre Adressen weiterhin erreichbar sind. Fragen Sie den Namen direkt ab und vergleichen Sie die Antwort mit der Adresse, von der Sie wissen, dass das Gerät sie hat.

Unter Linux zeigt resolvectl query nas.local, welcher Resolver geantwortet hat. Unter Windows nennt nslookup nas.local den Server, und ipconfig /all zeigt die Reihenfolge der Resolver. Wird das lokale Suffix jetzt vom Unternehmens-Resolver bearbeitet, leiten Sie das Suffix zurück an den lokalen Resolver oder verwenden Sie die IP-Adresse des Geräts.

Erkennung ist eine eigene Schicht. mDNS und Broadcast überqueren keinen gerouteten Tunnel, ein Gerät kann also über die Adresse erreichbar sein, während sein Name unsichtbar bleibt. Ein Reflektor oder ein lokaler DNS-Eintrag löst das; eine Route nicht.

Viertens: Prüfen Sie, ob die andere Maschine ebenfalls in einem VPN ist

Läuft auf der Maschine, die Sie erreichen wollen, ebenfalls ein VPN-Client, kann Ihre Sitzung ankommen, während ihre Antwort über den anderen Tunnel hinausgeht. Das erzeugt eine Verbindung, die sich aufbaut und dann hängt, oder einen RDP- und SSH-Versuch, der ohne Fehler auf Ihrer Seite in ein Timeout läuft. Prüfen Sie die Routing-Tabelle des anderen Hosts und seinen Standardweg, bevor Sie Ihren Client beschuldigen.

Prüfen Sie auch die Adresse, auf der der Dienst lauscht. Ein Listener, der nur an die Tunneladresse gebunden ist, nimmt Verbindungen aus dem VPN an und weist sie aus dem LAN ab, selbst wenn das Routing perfekt ist. Das ist eine Dienstkonfiguration, kein Netzwerkpfad, und sie ist häufig bei Verwaltungsschnittstellen, die auf die VPN-Adresse beschränkt wurden.

Halten Sie einen Verwaltungsweg bereit, der nicht vom Tunnel abhängt: eine statische Route, die Ihr Quellnetz nennt, eine weitere am LAN angeschlossene Schnittstelle oder eine Konsole, die den Tunnel vollständig umgeht. Diesen Weg zu entwerfen, nachdem die Sitzung abgebrochen ist, ist viel schwieriger, als ihn vor der nächsten Verbindung hinzuzufügen.

Wenden Sie die Reparatur an, die zur fehlgeschlagenen Prüfung passt

Zeigte die Routing-Tabelle eine Halb-Standard-Übernahme, wählen Sie Split-Tunnel, wenn die Richtlinie es erlaubt, und eine fest gebundene lokale Route, wenn nicht. Erwies sich die Adresse als öffentlich, wechseln Sie Test und Namen auf die private Adresse. Hat der Resolver die Seiten gewechselt, grenzen Sie das lokale Suffix ein oder nutzen Sie die Adresse. Ist der andere Host getunnelt, korrigieren Sie seinen Rückweg oder seine Listener-Bindung.

Ändern Sie eine Sache und wiederholen Sie dann dieselbe Prüfung. Eine für das falsche Subnetz hinzugefügte Route, ein Resolver-Suffix mit Tippfehler und eine fest gebundene Route auf einer Schnittstelle, die neu nummeriert, sehen alle wie der ursprüngliche Fehler aus. Die Wiederholung ist es, was eine Reparatur von einem Zufall trennt.

Notieren Sie die Route, die Adresse und den Resolver, die bei verbundenem VPN funktioniert haben. Die nächste Neuverbindung wird mindestens eines davon ändern, und die Notiz macht den nächsten Ausfall zu einem kurzen Vergleich statt zu einer neuen Untersuchung.