VPN und Heim-LAN im selben Subnetz: Erst die Route verfolgen

Du verbindest dich mit dem Büro-VPN, das Symbol in der Taskleiste wird grün, das Intranet lädt, und der Drucker zwei Meter entfernt antwortet nicht mehr. Die Freigabe, die heute Morgen funktionierte, läuft auf derselben Maschine in einen Timeout, und kein Protokoll erwähnt einen Drucker. Der Reflex ist DNS, weil ein Name, der sich nicht auflöst, wie ein Name aussieht, der nicht existiert, aber die Adresse ist das Problem: Zwei Adapter beanspruchen jetzt 192.168.1.0/24, und nur eine Route kann dieses Präfix gewinnen. Geh es in dieser Reihenfolge durch, und du siehst, welcher Adapter es genommen hat, bevor du etwas änderst.

Beim Symptom anfangen, nicht beim Tunnel

Der Hinweis ist der Umfang. Wenn das Intranet funktioniert und jedes lokale Gerät ausfällt, ist der Tunnel gesund und der lokale Pfad nicht. Wenn lokale Geräte funktionieren und das Intranet ausfällt, umgekehrt. Wenn alles außer einem Host funktioniert, siehst du eine einzelne Adresse, die auf beiden Seiten existiert.

Notiere eine lokale und eine entfernte Adresse, bevor du eine Einstellung anfasst. „Der Drucker“ ist nicht testbar; 192.168.1.40 ist es. Dieser eine Schritt verhindert die häufigste verlorene Stunde bei diesem Problem, nämlich DNS-Einstellungen wegen einer Routingentscheidung umzuschreiben.

Schritt 1: beide Adapter sehen, die das Präfix beanspruchen

Öffne Netzwerkverbindungen (ncpa.cpl) und lies die beiden Adapter nebeneinander. Der Ethernet-Adapter zeigt 192.168.1.50/24 mit Gateway 192.168.1.1. Der VPN-Adapter zeigt 192.168.1.201/24, vom Server gepusht. Beide sind legitim, beide glauben, das Präfix sei on-link, und der Stack hält dafür eine einzige Route.

Get-NetIPAddress -AddressFamily IPv4 listet die Adressen, und Get-NetIPInterface | Sort-Object InterfaceMetric zeigt die Reihenfolge, in der der Stack sie verwendet. Diese Metrikspalte ist die Entscheidung, die du gleich liest, also notiere die Zahlen, statt sie dir zu merken.

Widerlege die DNS-Theorie billig: Resolve-DnsName printer.office.lan liefert dieselbe Adresse wie gestern. Der Name wurde aufgelöst; das Paket verließ dann den falschen Adapter. Zwei Minuten hier sparen einen Nachmittag in den Resolver-Einstellungen.

Schritt 2: die Route lesen, die tatsächlich gewonnen hat

Find-NetRoute -RemoteIPAddress 192.168.1.40 zeigt die Schnittstelle, den nächsten Hop und die Quelle, die der Stack für diese Adresse verwenden würde. Behandle diese Ausgabe als Antwort, nicht als Hinweis. route print -4 liefert die ganze Tabelle, wenn du sehen willst, welcher Eintrag verloren hat und um wie viel.

Spezifität schlägt Absicht. Ein gepushtes 192.168.0.0/25 besiegt ein lokales 192.168.0.0/24, weil das Präfix länger ist, also verlassen 192.168.0.0 bis 192.168.0.127 den Rechner durch den Tunnel, während die obere Hälfte lokal bleibt. Dass ein halbes LAN ohne Fehlermeldung verschwindet, ist für diese Tabelle korrektes Verhalten.

tracert -d 192.168.1.40 bestätigt es außerhalb der Tabelle: Wenn der erste Hop eine Tunneladresse statt deines eigenen Routers ist, ist die Route die ganze Geschichte. Unter Linux lautet dieselbe Frage ip route get 192.168.1.40, was Quelladresse und Gerät in einer Zeile ausgibt. Wenn die Antwort tun0 nennt, hör auf, auf den Browser zu schauen.

Schritt 3: den Rückweg prüfen, bevor du den Client beschuldigst

Eine korrekte Vorwärtsroute scheitert trotzdem, wenn die Gegenseite nicht antworten kann. Wenn ein Client-LAN über den Tunnel erreicht wird, muss das Gateway dieses LAN wissen, wo der Tunnel-Pool liegt: ip route add 10.8.0.0/24 via 192.168.1.12 auf jenem Router, und push „route 192.168.1.0 255.255.255.0“ vom Server, damit die Clients den Rückweg kennen.

Ohne den ersten Eintrag verlässt die Antwort das Ziel in Richtung seines Standard-Gateways, das eine private Adresse an den Provider weiterreicht und verwirft. Das Symptom ist einseitig und leicht falsch zu lesen: Anfragen erscheinen auf tun0, Antworten nie.

Eine Masquerade-Regel auf dem VPN-Host erspart diese statische Route: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. Sie verbirgt außerdem die echten Quelladressen, was jede spätere Protokollfrage schwerer macht. Ein Zielhost mit falschem Standard-Gateway erzeugt dieselbe Stille, mit einer ICMP-Umleitung als bestem Fall und einem schwarzen Loch als Normalfall, weshalb die Aufzeichnung an beide Enden gehört.

Schritt 4: eine Reparatur wählen, mit der du leben kannst

Dafür werden fünf Reparaturen verwendet, und sie sind nicht austauschbar. Entscheide danach, was gleichzeitig erreichbar bleiben muss, nicht danach, welcher Befehl am kürzesten ist.

Metriken sind die billige Option und die, zu der Leute zuerst greifen. Die Änderung gilt für die Schnittstelle, wirkt also, solange der Tunnel steht, und gehört in ein Skript neben dem Client statt in eine Shell, die du vergisst. Sie kann keinen gleichzeitigen Zugriff auf dieselbe Adresse in zwei Netzen geben, und das ist die Grenze, die alle anderen die Tabelle hinunterschickt.

Das Heim-LAN umzunummerieren auf 10.10.0.0/24 ist die saubere Lösung: eine DHCP-Lease-Erneuerung plus die Reservierungen, Druckerwarteschlangen und fest eingetragenen Adressen, die den alten Bereich nennen. Die Büroseite umzunummerieren ist normalerweise nicht deine Entscheidung. IPv6 beseitigt die Kollision vollständig, wenn beide Netze es tragen, mit einem eindeutigen lokalen Präfix aus fd00::/8 statt etwas Merkbarem, aber teste die Anwendung über TCP, nicht mit einem Ping, denn ICMP kann funktionieren, während der Dienst es nicht tut.

OpenVPNs eigene Übersetzungsoption ist das letzte Mittel, vom Server in einen client-spezifischen Verzeichniseintrag gepusht. Sie nimmt vier Parameter nach dem Optionsnamen — Richtung, Netz, Netzmaske und Alias — und der Alias ist nicht optional: push "route 192.168.2.0 255.255.255.0" und push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0". Netz und Netzmaske sind der Bereich, den der Client sieht (192.168.2.0/24), der Alias ist der echte Bürobereich auf der Serverseite (192.168.1.0/24), und die gepushte Route macht diesen sichtbaren Bereich erreichbar. Das Büro erscheint diesem Client dann unter 192.168.2.x. Dokumentiere das Mapping im Profil, sonst debuggt die nächste Person es als Routingfehler.

Einen einzelnen Dienst zu veröffentlichen ist die schmale Variante der Übersetzung und braucht OpenVPNs Option überhaupt nicht. Eine DNAT-Regel auf dem VPN-Host veröffentlicht einen Port neu, sodass das LAN seine Adressen behält und den Dienst unter der Hostadresse erreicht, die es bereits kennt. Der Preis ist der übliche: Der Dienst sieht den VPN-Host als Quelle, also verlieren Protokolle pro Client und Reverse-Lookups ihre Bedeutung. Das deckt eine Druckerwarteschlange oder eine Admin-Seite ab, nicht Hosts auf beiden Seiten, die sich gegenseitig erreichen.

Was trotzdem nicht funktionieren wird, und was du festhalten solltest

Broadcast überschreitet keinen gerouteten Tunnel. DLNA, UPnP, NetBIOS-Browsing und Wake-on-LAN hängen von Broadcast oder Multicast ab, das ein tun-Gerät nicht trägt, also repariert keine Route die Erkennung. Bridging mit dev tap erweitert das Segment und damit DHCP-Broadcasts, ARP und jedes andere Erkennungspaket; bevorzuge eine Unicast-Host-Route wie route 192.168.2.1 255.255.255.255 für die LAN-seitige Adresse eines entfernten Routers.

Zwei Router, die beide 192.168.1.1 auf demselben Pfad verwenden, gehören zur selben Problemfamilie: Die lokale Adresse gewinnt immer, also bleibt die Seite des entfernten Routers unerreichbar, bis ein LAN umzieht. Ein zweiter Adapter ändert an keinem der beiden Fälle etwas.

Halte die Beweise fest, bevor du etwas änderst: ip route get oder Find-NetRoute, ping -c 3 an die betreffende Adresse, eine Traceroute und tcpdump -ni tun0 icmp auf dem Client, dann die Routing-Tabelle und NAT-Zähler auf dem Server. Ein Ping, der in eine Richtung funktioniert und in der anderen stirbt, deutet auf den Rückweg, nicht auf den Tunnel, und genau diese Unterscheidung entscheidet, welche der obigen Reparaturen du wirklich brauchst.