Der Full Tunnel kappt die SSH-Sitzung: Die Rückroute festnageln

Starte einen OpenVPN Client auf dem Rechner, an dem du über SSH arbeitest, und mitten im Befehl friert die Sitzung ein. Der Tunnel meldet eine bestehende Verbindung, der Host erreicht über ihn das Internet, und deine Tastatureingaben kommen weiterhin an, während nichts zurückkommt. Geändert hat sich nicht der Tunnel: Es ist der Rückweg für Pakete, die an dich adressiert sind, der jetzt der neuen Standardroute entspricht und in einen Tunnel läuft, den das entfernte Gateway nicht nutzt, um deinen Arbeitsplatz zu erreichen.

Was redirect-gateway tatsächlich installiert

In der Form def1 setzt redirect-gateway die Adressen 0.0.0.0/1 und 128.0.0.0/1 an die Stelle der Standardroute, statt sie zu überschreiben. Diese beiden Hälften decken den gesamten Adressraum ab, während beide längere Präfixe als 0.0.0.0/0 bleiben, sodass jedes Ziel ohne spezifischeren Treffer jetzt in den Tunnel läuft. Das ist der Mechanismus, den man sich merken muss, denn jede der folgenden Korrekturen funktioniert, indem sie einen spezifischeren Treffer installiert.

Deine Verwaltungsadresse ist eines dieser Ziele.

Der VPN-Server leitet den Verkehr seiner Clients in Richtung Internet weiter. Er hat keine Route für die öffentliche Adresse, von der du dich verbindest, und keinen Grund, diese Pakete anders zu behandeln als Verkehr, der von einem Client kommt, also verwirft er sie. Unterdessen erreichte die Anfrage, die du gesendet hast, den Host weiterhin, weshalb die Sitzung nur auf einer Seite lebendig aussieht.

ip route show table main | head -n 20
ip route get 198.51.100.23

Finde deine Quelladresse und den Pfad vor dem Tunnel

Liste auf dem Server die bestehende SSH-Verbindung auf und notiere die Peer-Adresse, von der sie kam. Diese Adresse muss deine Rückroute abdecken, und sie ist nicht immer die, die du erwartest: Ein Jump-Host, ein NAT-Gateway oder ein Carrier-Grade-Translator kann eine andere Quelle einsetzen.

Dann finde das physische Gateway und die Schnittstelle, die den Verkehr vor dem Start des Tunnels getragen haben. In der def1 Anordnung ist die Standardroute unter den Halb-Standardrouten weiterhin vorhanden, die Information ist also verfügbar, wobei das Lesen einer langen Routentabelle mit bloßem Auge Fehler einlädt.

Halte beide Werte und den Schnittstellennamen zusammen fest, denn die Route, die du gleich hinzufügst, braucht alle drei. Wenn der Host eine Policy-Routing-Regel nutzte, um seinen Uplink zu wählen, wird eine einfache Route womöglich gar nicht konsultiert, und diese Möglichkeit ändert die Korrektur.

Nagle eine Host-Route fest, die die Halb-Standardrouten übertrumpft

Eine /32-Route ist länger als jede der beiden Halb-Standardrouten, sodass Antworten an deine Adresse sie dem Tunnel vorziehen. Der nächste Hop ist das Gateway von vor dem Tunnel und das Gerät ist die physische Schnittstelle, was das Paket auf dem Pfad hält, den es vor dem Tunnel nutzte.

ip route add 198.51.100.23/32 via 203.0.113.1 dev eth0

Prüfe mit einem Lookup statt durch Ansehen der Tabelle: Die Antwort muss eth0 und das Gateway nennen, niemals tun0.

OpenVPN fügt bereits eine Host-Route zur eigenen Adresse des VPN-Servers aus demselben Grund hinzu, sodass das Muster vertraut ist und die Verwaltungsadresse schlicht eine weitere Ausnahme darstellt. Nutze zur Behebung nicht route-nopull, denn es verwirft die gepushten Routen, die der Tunnel braucht, einschließlich des entfernten Netzwerks und der DNS-Optionen.

So übersteht sie einen Reconnect

Eine von Hand hinzugefügte Route verschwindet, wenn der Client sich neu verbindet und seine eigene neu installiert, was aus einer Korrektur einen wiederkehrenden Ausfall macht. Hänge den Befehl an etwas, das läuft, nachdem die Routen installiert sind.

Sowohl ein route-up als auch der Pre-up-Hook des Netzwerkmanagers funktionieren, und die verlässliche Prüfung ist ein Reconnect, gefolgt von demselben Lookup.

Unter Windows ist das Äquivalent eine persistente Route, hinzugefügt mit -p, die Neustarts übersteht, aber nach einer Netzwerkänderung weiterhin auf das richtige Gateway zeigen muss. Schreibe unabhängig von der Plattform den Grund neben die Route: Der nächste Administrator muss wissen, dass sie existiert, um eine Verwaltungssitzung zu schützen, und nicht, weil das Netzwerkdesign es verlangte.

Wenn eine festgenagelte Route noch nicht reicht

Reverse-Path-Filtering kann ein Paket verwerfen, das auf der einen Schnittstelle ankommt und über eine andere hinausgeht, und genau das erzeugt eine festgenagelte Route. Prüfe den effektiven rp_filter-Wert, bevor du irgendetwas global deaktivierst, und behebe lieber die Asymmetrie, als die Prüfung abzuschalten. Es gilt die Einstellung pro Schnittstelle, und der Loose-Modus protokolliert oft nur die Asymmetrie, statt das Paket zu verwerfen. Lies beides, bevor du folgerst, der Filter sei deine Schuld.

Hosts mit Policy-Routing brauchen ebenso eine Regel wie eine Route, denn die Regelbasis wählt die Tabelle aus, bevor die Route darin konsultiert wird. Eine Route in der main-Tabelle ist für einen Fluss unsichtbar, der einer Regel auf eine andere Tabelle entspricht. Lies die Regeln, bevor du etwas zu main hinzufügst. Wenn eine Regel den Verwaltungsverkehr bereits abdeckt, gehört die Ausnahme stattdessen in die Tabelle dieser Regel.

Halte während des Tests eine Out-of-Band-Konsole offen und prüfe von einer zweiten Anmeldung aus nach, bevor du die trennst, die du gerade benutzt. Eine Route, die deinen eigenen Verwaltungsverkehr in den Tunnel schickt, kappt die Verbindung, durch die du sie reparierst. Wieder hineinzukommen bedeutet dann eine serielle Konsole oder einen Rescue-Boot, was ein schlechter Tausch dafür ist, einen Prüfschritt zu überspringen.