Warum ein Server hinter einem VPN-Client durch den Tunnel antwortet

Eingehende Verbindungen zu einem Host, der auch einen VPN-Client betreibt, scheitern auf sehr spezifische Weise: Der Handshake kommt an, der Daemon antwortet, und der Client erhält nichts zurück. Nichts blockiert den Port. Die Antwort verließ den Tunnel, weil der Tunnel die Standardroute besitzt und der Kernel Antworten nach Ziel routet, nicht nach der Erinnerung daran, woher die Anfrage kam. Der Daemon ist in Ordnung, und der Port ist offen.

Die Antwort wird geroutet, nicht erinnert

Ein VPN-Client, der eine Standardroute installiert, fügt einen Eintrag hinzu, der das LAN-Gateway übertrifft, sei es über die Metrik oder indem er den Raum in zwei spezifischere Hälften teilt. Ausgehende Pakete wählen nun das Tunnel-Interface. Der Kernel fragt nie, woher das Paket, auf das geantwortet wird, ursprünglich kam. Diese eine Auslassung erklärt jedes folgende Symptom.

Die Hinrichtung wird nach Ziel geroutet, die Rückrichtung ebenso. Die Antwort ist an einen öffentlichen Client adressiert, den der Tunnel bereitwillig befördert. Das andere Ende erhält ein Paket, dessen Quelle es nicht besitzt, verwirft es, und der ursprüngliche Client wartet, bis die Zeit abläuft.

Strenge Reverse-Path-Filterung kann das eingehende Paket verwerfen, bevor der Daemon es überhaupt liest. Prüfe diesen Zähler zuerst, denn ein Filter-Drop und ein Routing-Fehler sehen von außen identisch aus.

ip route show default
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.eth0.rp_filter
nft list ruleset | grep -A3 'hook forward'

Der erste Befehl zeigt, welche Standardroute gerade gewinnt. Der zweite meldet, ob strenge Filterung global oder pro Schnittstelle gilt, und der dritte zeigt jede Weiterleitungsketten-Regel, die beteiligt sein könnte.

Drei Wege, den Rückweg zu erhalten

Das Dienstziel vom Tunnel auszunehmen ist die engste Option. Eine Hostroute zum LAN-Gateway plus ein Daemon, der an die physische Adresse statt an jede Adresse gebunden ist, hält diesen einen Fluss außerhalb des Tunnels. Die Änderung ist lokal und leicht rückgängig zu machen.

Policy-Routing ist die allgemeine Antwort. Eine Regel, die an der Quelladresse oder an einer Firewall-Marke ansetzt, wählt eine Tabelle, deren Standard auf das WAN-Gateway zeigt, während die eigenen Verbindungen des Hosts weiter den Tunnel nutzen. Halte die Priorität explizit, damit die Regel später nicht überschattet werden kann.

ip rule add from 203.0.113.25/32 table 100 priority 100
ip route add default via 192.0.2.1 dev eth0 table 100
ip route get 198.51.100.7 from 203.0.113.25

Die ersten beiden Befehle bauen den alternativen Weg für Antworten mit Quelladresse im öffentlichen Bereich. Der dritte fragt den Kernel, welchen Weg genau diese Quelle und dieses Ziel nehmen würden, und so bestätigst du, dass die Regel überhaupt wirkt.

Quellübersetzung ist die dritte Option und die einzige, die einen Router übersteht, der vor dem Dienst bereits NAT betreibt. Die Antwort muss zu diesem Router zurück, und Maskierung auf das WAN-Interface erreicht das, während sie den Client aus den Dienstprotokollen verbirgt. Die Standardroute nach dem Verbinden von Hand zu ersetzen ist eine Diagnose, denn der Client schreibt die Tabelle beim nächsten Verbindungsaufbau neu.

Wenn die Kiste auch für ein LAN routet

Derselbe Fehler zeigt sich einen Hop weiter draußen, wenn der Host für Geräte hinter sich routet. Eine eingehende Verbindung wird an ein internes Gerät weitergeleitet, dessen einziger Rückweg der Tunnel ist, und die Antwort erreicht den externen Client von der Adresse des Anbieters. Das interne Gerät arbeitet die ganze Zeit korrekt.

Die Verbindungsverfolgung sieht dann eine Antwort für einen Fluss, den sie nie aufgezeichnet hat, und verwirft sie. Zielübersetzung liefert die eingehende Verbindung an das Gerät, und Quellübersetzung lässt die Antwort so erscheinen, als stamme sie vom Router selbst.

Eine Policy-Route, die den weitergeleiteten Port auf dem WAN hält, während der eigene Verkehr des Routers den Tunnel nutzt, ist das sauberere Äquivalent. Ohne Quellübersetzung ist die Antwort an den externen Client adressiert, und das interne Gerät hat für diese Adresse überhaupt keine Route.

Drei Sonden, die die Ursachen trennen

Führe drei Sonden aus: eine Verbindung in die Kiste aus dem Internet, eine Verbindung aus ihr zu einem öffentlichen Host und eine Namensauflösung. Wenn die ersten beiden nicht übereinstimmen, ist der Rückweg schuld. Wenn Namen in beide Richtungen scheitern, ist der Resolver ein anderer Fehler, der nur den Tunnel teilt.

Behebe zuerst die Routing-Frage, dann sieh dir Namen an. Beides zu vermischen ist der Weg, wie ein funktionierender Server für einen kaputten Resolver beschuldigt wird.

Notiere, welche Schnittstelle die Ausnahme nennt, und halte die Konfiguration unter Versionskontrolle. Eine Regel gegen eine Schnittstelle, die nach einem Upgrade umbenannt wird, besteht heute und scheitert nach dem nächsten Neustart.