VPN verbindet, aber LAN-Geräte sind nicht erreichbar: Was zu prüfen ist

Das Gateway antwortet auf seine eigene Adresse, während dahinter nichts antwortet. Folgen Sie dem Client-Flow Hop für Hop, um die fehlerhafte Grenze zu finden.

Verkehr tritt in den Tunnel ein, das Gateway antwortet auf seine eigene Adresse, und dahinter antwortet nichts. Dieses Muster ist verbreitet und kein Widerspruch: Eine Antwort vom Gateway beweist, dass der Tunnel beendet wurde, und sie beweist nichts darüber, was mit einem Paket geschieht, das dahinter adressiert ist. Die beiden Tests beanspruchen unterschiedliche Codepfade auf derselben Maschine.

Testen Sie ab jetzt etwas auf der anderen Seite des Gateways. Die eigene Adresse des Gateways antwortet weiter, so defekt die Weiterleitung auch sein mag.

Das Gateway antwortet aus seinem eigenen Stack

Ein an das Gateway adressiertes Paket wird an seinen lokalen Eingabepfad zugestellt, wo der Kernel entscheidet, ob ein lauschender Socket es annimmt. Ein an einen Host hinter dem Gateway adressiertes Paket wird stattdessen an den Weiterleitungspfad zugestellt, wo ein anderer Satz von Prüfungen gilt. Die Weiterleitung kann vollständig deaktiviert sein oder vom Kernel aktiviert und dann von einer Filterregel verworfen werden, die den Tunnel nie erwähnt. Nichts davon betrifft die eigene Antwort des Gateways, weshalb das Symptom so zuverlässig in die Irre führt.

Administrationsseiten, die über den Tunnel erreicht werden, gehören ebenfalls zur ersten Kategorie. Sie sind ein Beleg über den Tunnel, nicht über das Netz dahinter.

Folgen Sie dem Flow bis zur ersten Grenze, die ihn verwirft

Beginnen Sie beim Client und bestätigen Sie die Route und die Quelladresse, die der Flow verwenden wird. Beobachten Sie dann am Gateway das Eintreffen genau dieses Flows und erneut denselben Flow beim Verlassen in Richtung LAN. Kommt er nie an, liegt das Problem auf der Clientseite oder bei den erlaubten Präfixen des Tunnels. Kommt er an und geht nie hinaus, liegt das Problem in der Weiterleitung oder in einem Filter auf dem Vorwärtspfad, und die Aufzeichnung hat bereits gesagt, welches von beidem.

Denselben Test vom Gateway aus auszuführen verbirgt die interessante Hälfte, denn ein vom Gateway stammendes Paket hat eine andere Quelle und eine andere Rückkehrerfordernis. Verwenden Sie für jeden Schritt den Flow des Clients mit seiner eigenen Quelladresse. Eine Aufzeichnung auf der falschen Schnittstelle liefert selbstsicheren Unsinn.

Rückrouten und Host-Firewalls scheitern getrennt

Sobald das Paket den Host erreicht, müssen drei weitere Dinge gelten. Der Dienst muss auf der Adresse lauschen, an die das Paket gesendet wurde, die Host-Firewall muss es annehmen, und die Antwort muss eine Route zurück zum Client-Pool haben. Das Letzte scheitert oft, weil die Standardroute des Hosts auf einen Router zeigt, der vom Tunnelbereich noch nie gehört hat. Das Ergebnis ist eine Verbindung, die aus Sicht des Hosts zustande kommt und in der anderen Richtung still stirbt.

Testen Sie den Rückweg gezielt, indem Sie vom Client senden und auf die Rückkehr achten. Eine einseitige Aufzeichnung klärt in Sekunden, was eine Stunde Spekulation nicht klärt.

Bestätigen Sie jeden Hop mit der Quelle des Clients

Führen Sie die Prüfungen der Reihe nach aus und bewahren Sie jede Ausgabe auf, denn der Wert liegt im Vergleich und nicht in einer einzelnen Zeile. Die Befehle unten legen die Quelladresse fest, zeigen die gewählte Route und zeichnen beide Seiten der Weiterleitung auf. Ersetzen Sie Ihren eigenen LAN-Host und Ihr Tunnel-Interface.

ip route get 192.168.50.20 from 10.8.0.2
ping -I 10.8.0.2 -c 3 192.168.50.20
sudo tcpdump -ni tun0 host 192.168.50.20
sudo tcpdump -ni br0 host 192.168.50.20

Die Routenabfrage zeigt, ob der Client dieses Paket überhaupt in den Tunnel senden würde, und das Ping zeigt, ob etwas vom Host zurückkam. Der Vergleich der beiden Aufzeichnungen trennt Ankunft vom Ausgang, denn ein Rahmen auf der Tunnel-Schnittstelle ohne Gegenstück auf der LAN-Schnittstelle ist eine Weiterleitungsentscheidung und kein Dienstfehler. Wenn beide Aufzeichnungen die Anfrage zeigen und nur eine die Antwort, ist die Rückroute der verbleibende Verdächtige.

Notieren Sie, welche Adresse geantwortet hat und welches weitergeleitete Ziel fehlgeschlagen ist. Dieser Satz macht den Bericht handlungsfähig statt zu der Behauptung, der Server sei unerreichbar.

Ähnliche Artikel