VPN-Client auf einem LAN-Server: Warum Antworten den falschen Weg nehmen

Die Symptome folgen einem Muster: Ein Host läuft, dann verbindet er sich als Client mit einer VPN, und nun erreichen ihn LAN-Clients, während seine Antworten verschwinden. Ein Mitschnitt auf dem Host zeigt, dass die Antworten über das Tunnelgerät statt über die LAN-Schnittstelle abgehen. Am Tunnel ist nichts defekt, und die Lösung ist eine Route, keine Neuverbindung. Arbeiten Sie die vier Prüfungen unten der Reihe nach ab und hören Sie bei der ersten auf, die fehlschlägt.

Eine Antwort ist ein neues Paket, keine Umkehr

Es hilft, die Vorstellung aufzugeben, dass eine Antwort auf dem Weg zurückläuft, den eine Anfrage genommen hat. Routing wird pro Paket und pro Richtung auf dem sendenden Host entschieden. Eine Anfrage, die aus 10.64.0.23 im Tunnel ankam, erzeugt keinen Rückweg; wenn der Host antwortet, wird diese Antwort als neues Paket gegen die Tabelle geprüft und verlässt den Host über die Route, die gewinnt.

Deshalb erzeugt ein Full-Tunnel-Client auf einer Maschine, die auch ein LAN bedient, einen so verwirrenden Fehler. Der Client installiert eine Standardroute oder die beiden Halb-Standardrouten, die manche Clients bevorzugen, und die Antwort an einen LAN-Client passt nun auf den Tunnel. Sie geht zum Anbieter, der keinen Grund hat, sie weiterzuleiten, und der LAN-Client sieht eine Zeitüberschreitung, obwohl der Host läuft und lokal antwortet. Der Mitschnitt macht es offensichtlich, und die Routing-Tabelle erklärt es.

Behalten Sie zwei Subnetze im Kopf, während Sie den Rest lesen. Das eine ist der VPN-Adresspool, aus dem die entfernten Clients kommen, in diesem Beispiel 10.64.0.0/24. Das andere ist das LAN, das weiter funktionieren muss, 172.16.24.0/24 mit seinem Router unter 172.16.24.1. Der Fehler ist, dass der Verkehr zwischen ihnen von der Standardroute entschieden wird.

Beweisen Sie es mit Mitschnitt und Abfrage

Bevor Sie etwas ändern, bestätigen Sie, welches Gerät die Antwort verwenden wird. Eine Abfrage ist schneller als ein Mitschnitt und beantwortet genau die Frage, die der Kernel beim Bau des Pakets beantwortet.

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

Lesen Sie die Antwort in zwei Teilen. Nennt sie dev tun0, kapselt der Host die Antwort ein und übergibt sie dem Anbieter, und der LAN-Client wird sie nie sehen. Nennt sie dev eth0, aber der Client läuft weiter in eine Zeitüberschreitung, ist die Route bereits richtig und das Paket wird später verworfen, was ein anderes Problem mit einer anderen Lösung ist.

Der Mitschnitt im selben Schritt beseitigt den Zweifel, den ein Ping nicht beseitigen kann. Eine Echo-Antwort, die beim LAN-Client ankommt, beweist, dass irgendein Weg funktioniert, nicht welche Schnittstelle ihn getragen hat, führen Sie den Mitschnitt also auf dem Host selbst aus und beobachten Sie, wo die Frames ihn verlassen. Ein Drucker im selben Subnetz antwortet weiter, weil seine direkte Route spezifischer ist als die Standardroute des Tunnels. Ein weitergeleiteter Port scheitert genau wie jeder andere Fluss, weil die Tabelle die Schnittstelle wählt und nicht die Verbindung.

Installieren Sie die engste Route, die den Tunnel übertrumpft

Die Präfixlänge entscheidet, nicht die Metrik, deshalb gewinnt eine Route für den Client-Pool über den LAN-Router gegen jede Standardroute, die der VPN-Client installiert. Metrik-Chirurgie ist nicht nötig, und die Standardroute kann genau dort bleiben, wo der Client sie hingesetzt hat.

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

Verwenden Sie replace statt add, weil ein Client, der sich neu verbindet, seinen eigenen Eintrag installiert haben wird und ein zweites add mit einem Fehler über eine bereits vorhandene Route scheitert, der wie ein Berechtigungsproblem klingt. Auf einem Windows-Host ist das Äquivalent route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, wobei -p den Eintrag über Neustarts hinweg hält, da der Client die Tabelle neu aufbauen kann, wenn der Tunnel wieder hochkommt. Auf einem aktuellen Windows-Host ist das unterstützte Äquivalent New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, wobei der ältere Befehl route als Altform erhalten bleibt.

Ein Detail entscheidet, ob das korrekt oder nur plausibel ist: Der nächste Hop muss der Router sein, der den Weg zurück zu den Clients tatsächlich besitzt. Die Route auf eine Adresse zu zeigen, die selbst durch den Tunnel erreicht wird, erzeugt eine Schleife, die sich als zeitweiliger Verlust statt als sauberer Fehler zeigt. Bestätigen Sie, dass der nächste Hop im LAN-Subnetz liegt, bevor Sie die Zeile ausführen.

Behalten Sie die Antwort nach einer Neuverbindung

Eine von Hand hinzugefügte Route überlebt bestenfalls bis zur nächsten Neuverbindung. Ist der Client-Pool dynamisch, fixieren Sie ihn in der Serverkonfiguration, damit das Präfix, das Sie geroutet haben, das Präfix bleibt, das Clients erhalten; sonst zeigt der Eintrag auf einen leeren Bereich, und das Symptom kehrt Wochen später ohne erkennbare Ursache zurück. Die Route in das eigene Up-Skript des Clients zu schreiben ist die andere verlässliche Option, weil es läuft, nachdem der Client die Tabelle neu geschrieben hat.

Eine zustandsbehaftete Firewall kann eine korrekte Route dennoch besiegen. Wenn der Mitschnitt nun zeigt, dass die Antwort über eth0 abgeht, und der Client weiter in eine Zeitüberschreitung läuft, prüfen Sie, ob der Host das Paket vor dem Senden verwirft. Strenge Reverse-Path-Filterung und net.ipv4.conf.all.rp_filter auf 1 gesetzt verwerfen Pakete, deren Quelle nicht über die Schnittstelle zurückgeroutet würde, auf der sie ankamen, was genau der asymmetrische Fall ist, den Sie gerade erzeugt und dann behoben haben, und der Conntrack-Zustand erzählt dieselbe Geschichte für weitergeleitete Ports.

Die letzte Prüfung ist die, die Leute überspringen: Wiederholen Sie die Abfrage, nachdem der Tunnel unten und wieder oben war. Vier Werte sollten mit dem übereinstimmen, was Sie notiert haben: das Ziel, der nächste Hop, das Gerät und die gewählte Quelle. Hat sich einer davon bewegt, hat der Client die Tabelle neu geschrieben, und die Lösung gehört in seine Hooks statt in eine Shell-Historie.