LAN-Router plus VPN-Client: zwei Geräte, zwei Routing-Tabellen

Zwei Geräte leiten das Paket weiter, und jedes führt seine eigene Tabelle. Der LAN-Router weiß, dass das entfernte Präfix dem VPN-Client gehört, und der VPN-Client weiß, wie er dieses Präfix durch seinen Tunnel erreicht. Konfigurieren Sie nur die erste Tabelle, und das Paket kommt bei einer Maschine an, die keine passende Route hat, also verlässt es sie wieder über die Standardroute. Das ist der ganze Fehler, und aus LAN-Sicht sieht er wie eine Routingschleife aus, weil er fast eine ist.

Zeichnen Sie die beiden Hops, bevor Sie eine Route anfassen

Nehmen Sie ein anschauliches Layout: LAN-Hosts auf 192.168.50.0/24, der gewöhnliche Router auf 192.168.50.1, ein eigener Client auf 192.168.50.15 und ein entferntes LAN auf 10.60.0.0/24, das nur über den Tunnel erreichbar ist, den dieser Client hält. Keiner der beiden privaten Bereiche überschneidet sich mit dem anderen, und der Tunnel hat seinen eigenen Adressplan.

Beide privaten Bereiche sind wichtig, weil sie entscheiden, welches Gerät antworten kann. Die Gegenseite sieht das Paket von der Tunneladresse des Clients ankommen, und ihre Antwort muss einen Weg zurück zu 192.168.50.0/24 finden. Ist nur die ausgehende Richtung konfiguriert, kann die Anfrage funktionieren, während die Antwort verschwindet.

Schritt 1: Richten Sie den Router auf den Client, nicht auf den Tunnel

Fügen Sie auf dem LAN-Router eine Zielroute hinzu, deren nächster Hop die LAN-Adresse des Clients ist:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

Dieser Eintrag sagt „liefere es an die Maschine, die tunneln kann“. Er sagt nichts darüber, wie der Tunnel aufgebaut wird, und er ersetzt nicht die eigene Route des Clients. Auf einem verwalteten Router lebt das Äquivalent auf der Seite für statische Routen des Geräts; auf einem Linux-Router gehört es in die Schnittstellenkonfiguration, die das LAN besitzt, nicht in eine Shell, die Sie schließen.

Prüfen Sie die Antwort des zweiten Befehls. Meldet er den Client als gateway und die LAN-Schnittstelle als device, ist der erste Hop korrekt, und die restliche Arbeit liegt auf der anderen Maschine.

Schritt 2: Geben Sie dem Client eine eigene Route auf der Tunnelseite

Der Client empfängt nun ein Paket für 10.60.0.0/24 und sieht in seiner eigenen Tabelle nach. Hat seine Tunnelkonfiguration eine Route für dieses Präfix installiert, läuft das Paket verschlüsselt weiter. Wenn nicht, passt das Paket auf die gewöhnliche Standardroute und geht zurück zu 192.168.50.1, der es erneut an den Client schickt.

Schauen Sie nach, bevor Sie etwas hinzufügen:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

Eine fehlende Präfixroute in allen Tabellen ist der Befund, den Sie suchen. Fügen Sie sie über die eigene Konfiguration des Tunnels hinzu, damit der nächste Reconnect sie wieder installiert; ein manuelles ip route add verschwindet mit der Sitzung und lässt den Fehler zum ungünstigsten Zeitpunkt zurückkehren. Der nächste Hop ist die Tunnelschnittstelle oder die Adresse, die die VPN als ihren Peer vergibt, je nach Client, und die Peer-Adresse sollte aus dem aktuellen Profil stammen und nicht aus einer alten Notiz.

Die Schleife ist, wenn sie auftritt, praktisch nicht unendlich: Die TTL sinkt bei jedem Durchlauf, und das Paket stirbt mit einer Time-Exceeded-Meldung. Deshalb kann ein wiederholtes traceroute einen Zyklus nahelegen, während ein Client, der schlicht nicht weiterleitet, dasselbe Paket still verwirft.

Schritt 3: Erlauben Sie die Weiterleitung und wählen Sie den Rückweg

Empfangen und Weiterleiten sind verschiedene Berechtigungen. net.ipv4.ip_forward=1 auf dem Client erlaubt Transit auf Kernel-Ebene, und eine Firewall-Regel muss ihn weiterhin zwischen LAN-Schnittstelle und Tunnel erlauben. Eine Regel, die den Zugriff auf die eigene Verwaltungsseite des Clients erlaubt, erlaubt keinen Transit zum entfernten LAN, und der Unterschied ist leicht zu übersehen, wenn derselbe Host lokal auf Pings antwortet.

Die Gegenseite hat das Spiegelproblem. Sie muss wissen, dass 192.168.50.0/24 über diesen authentifizierten Client erreichbar ist. Mit OpenVPN bedeutet das normalerweise eine Pro-Client-Route, die die Serverkonfiguration anstößt, oder eine client-spezifische Datei auf dem Server, die das LAN hinter dem Client deklariert. Ohne sie verwirft das entfernte LAN die Antwort entweder oder schickt sie an sein eigenes Standard-Gateway, also ins Internet.

Quellübersetzung ist die Alternative, wenn das LAN-Präfix nicht angekündigt werden kann. Eine begrenzte Masquerade-Regel auf dem Client schreibt die Quelle auf die Tunneladresse um, und Antworten kehren dann von selbst zurück. Sie verbirgt außerdem, welcher LAN-Host die Anfrage gestellt hat, und sie erlaubt der Gegenseite nicht von sich aus, Verbindungen nach innen zu beginnen. Wählen Sie diesen Kompromiss bewusst, statt eine pauschale Masquerade hinzuzufügen und den Nebeneffekt später zu entdecken.

Schritt 4: Machen Sie beide Entscheidungen dauerhaft und testen Sie dann den echten Pfad

Jede Route hat einen Eigentümer, und der Eigentümer ist die Konfiguration, die beim Booten oder beim Reconnect neu erzeugt wird. Auf dem Router kann das ein statischer Routeneintrag sein; auf dem Client kann es das VPN-Profil, NetworkManager oder systemd-networkd sein. Prüfen Sie, indem Sie den Tunnel neu verbinden und den Client neu starten, und lesen Sie dann die Tabelle erneut, statt der Änderung zu vertrauen.

Lassen Sie die Standardroute, die die äußere Verbindung des Tunnels trägt, unangetastet. Sie zu ersetzen, um das Setup zu „vereinfachen“, bricht den verschlüsselten Pfad, bevor irgendein innerer Verkehr ihn nutzen kann, und das Symptom ist ein Tunnel, der sich nach der Änderung nie wieder aufbaut.

Testen Sie von einem gewöhnlichen LAN-Host aus, nicht vom Client, denn eine Anfrage, die auf dem Client entsteht, übt den ersten Hop des Routers nie aus. Rufen Sie einen Dienst ab, den es nur im entfernten LAN gibt, und bestätigen Sie den Antwortkörper, und prüfen Sie dann die Zähler oder Logs des Clients, um den Transit zu sehen. Ein inneres traceroute mit privaten Hops beweist Weiterleitung, nicht Verschlüsselung: Der äußere Pfad ist eine eigene Beobachtung, und nur die Schnittstellenzähler des Tunnels zeigen, was durch ihn hinausging.