Keine Route repariert einen VPN-Pool, der dein LAN überlappt

Die App behauptet einen gesunden Tunnel, und doch antwortet die Hälfte der Ziele, die du brauchst, nie. Der Reflex ist, eine Route hinzuzufügen oder eine Metrik zu senken, und genau dieser Reflex ist der Mythos, den man zuerst töten sollte. Wenn das eigene LAN des Clients und der Pool des Tunnels dasselbe Präfix beanspruchen, hält die Routing-Tabelle zwei unvereinbare Tatsachen, und weder eine Default-Route noch eine Metrik löst sie auf. Die Reparatur ist eine Adressierungsentscheidung, und keine Routenbearbeitung ersetzt sie.

Warum eine zusätzliche Route ein Präfix nicht teilen kann

Eine Route kann zwei Ansprüche auf ein Präfix nicht trennen, deshalb ist der vernünftige Schritt, die Suche nach der richtigen Routenzeile aufzugeben. Der Stack stellt kein identisches Präfix vor die verbundene Route, und ein spezifischerer Eintrag fängt die Adresse zwar ab, macht aber den lokalen Host, dem sie gehört, unerreichbar. Was wie ein Routing-Problem aussieht, ist eine Adresskollision, und beide Reparaturen ändern Adressen statt Routen. Prüfe die Behauptung auf deiner eigenen Maschine, bevor du sie akzeptierst.

ip route get 192.168.1.50
route -n get 192.168.1.50
Find-NetRoute -RemoteIPAddress 192.168.1.50

Frag das System nach einer einzelnen Adresse und notiere, welche Schnittstelle es nennt. Linux, macOS und Windows antworten jeweils mit einer schreibgeschützten Abfrage, die die gewählte Schnittstelle und den nächsten Hop meldet, ohne etwas zu senden. Wenn die Antwort auf den physischen Adapter zeigt, während der Tunnel steht, behandelt der Kernel die Adresse als on-link und nicht als etwas, das der Tunnel tragen könnte.

Stelle das vom Anbieter gewährte Präfix neben das, das der Heimrouter bedient, und vergleiche beide als Zeichenketten. Eine exakte Übereinstimmung ist der klare Fall, und ein breiterer Anbieter-Pool, der das Heim-Subnetz enthält, scheitert genauso, ist aber leichter zu übersehen. Zwei Präfixe, die nur ähnlich aussehen, sind keine Kollision, also schreibe beide auf, bevor du etwas änderst.

Lies den Pool, den der Client tatsächlich bekommen hat

Lies, was der Client empfangen hat, nicht die Marketingseite des Anbieters. Erhöhe die Ausführlichkeit des Logs eines OpenVPN-Clients, und die vom Server geschobenen Routen erscheinen darin und zeigen die Tunnel-Präfixe; anderswo taucht der Pool in den Verbindungsdetails oder auf dem Adapter selbst auf. Bitte den Anbieter um die vollständige Liste der privaten Bereiche, die er verwendet, denn ein einzelnes /24 heute können morgen zwei sein. Die üblichen RFC 1918-Blöcke zu meiden ist nicht dasselbe, wie die Zuweisung zu meiden, die du tatsächlich bekommen hast.

Ein Pool kann auch schrumpfen oder zwischen Regionen wandern, also braucht die Liste ein Datum und einen Verantwortlichen. Behandle jede Anbieterantwort, die älter ist als deine letzte Planänderung, als Vermutung und nicht als Tatsache. Frage erneut, bevor du dich auf einen Bereich festlegst, und bewahre die Antwort bei den Netzwerknotizen auf, damit die nächste Person den Beleg erbt.

Umnummerieren ist die Reparatur, die du machen kannst

Wenn der VPN-Server nicht deiner ist, um ihn zu ändern, ist das Verschieben des Heim-LANs die einzige verfügbare Reparatur, und das ist die übliche Situation bei einem kommerziellen Anbieter. Wähle einen Bereich außerhalb des Anbieter-Pools und außerhalb der Bereiche, die du später brauchen könntest, und prüfe ihn gegen jeden anderen Standort, den du über einen Tunnel erreichst. Erwarte eine kurze Ausfallzeit und einen längeren Schwanz vergessener Geräte: eines, das noch die alte Adresse hält, scheint zu funktionieren, bis es das Gateway braucht.

1. Zuerst Inventur: die eigene Adresse des Routers, der DHCP-Bereich, Reservierungen, Portweiterleitungen und jedes Gerät, dessen Adresse von Hand eingetippt wurde.
2. Dann ändere das LAN-Präfix des Routers und den DHCP-Bereich gemeinsam in einem Wartungsfenster und erneuere die kabelgebundenen Leases vor den funkgebundenen.
3. Als Nächstes korrigiere die statischen Adressen: Drucker, Netzwerkspeicher, alles mit fest eingetragenem Gateway.
4. Zum Schluss verbinde den VPN-Client neu und bestätige, dass die Tunneladresse nicht mehr mit dem LAN kollidiert.

Arbeite die Adressen in dieser Reihenfolge ab statt alle auf einmal, und halte den alten Bereich eine Weile dokumentiert, damit ein veraltetes Gerät erkennbar statt rätselhaft ist. Ein Gerät, das nie erneuert, meldet sich dadurch, dass es das Gateway nicht erreicht, was ein weit besserer Hinweis ist als ein Anruf beim Support. Wenn der Router Leases für mehr als einen Tag ausgibt, kürze sie für die Dauer des Fensters.

Was ein Alias kann und was nicht

Wo der Server deiner ist, kann das Übersetzen von Adressen auf dem Client das entfernte Präfix in einem freien lokalen Bereich sichtbar machen, sodass derselbe Host unter einer zweiten Adresse antwortet. Das Community-OpenVPN tut das mit client-nat, und diese Direktive ist spezifisch für jenen Client und fehlt in den kommerziellen und mobilen Clients, mit denen man sie üblicherweise vergleicht. Die Anordnung braucht eine Route, die zur Übersetzung passt, einen freien Bereich für den Alias und einen Server, der die unübersetzte Adresse des Clients beantworten will. Nichts davon hilft, wenn der Client zu einem verwalteten Anbieter gehört, den du nicht konfigurieren kannst.

Sobald die Änderung greift, erreiche einen lokalen und einen entfernten Host zuerst über die Adresse und dann über den Namen und notiere, welche Route das System jeweils wählt. Ein Name kann noch in den alten Bereich auflösen, also verdienen Adressen und Namen getrennte Prüfungen. Starte einen Client und ein geräteseitiges Gerät neu, falls eines davon die Änderung überstanden hat, denn gecachte Nachbareinträge leben länger als die Bearbeitung.

Schreib die Präfixe, auf die du dich geeinigt hast, dorthin, wo Leute tatsächlich nachsehen: die Netzwerknotizen, das Kommentarfeld des Routers, die Onboarding-Seite. Jemand wird wieder 192.168.1.0/24 wählen, und die Kollision kommt mit ihm zurück.