Starten Sie einen VPN-Client über SSH? Legen Sie zuerst Ihre eigene Route fest

Sie melden sich per SSH auf einem Build-Host an, starten dort den VPN-Client, und die Sitzung antwortet nicht mehr. Nichts ist abgestürzt, und nichts sieht im offensichtlichen Sinn falsch konfiguriert aus. Der Client hat eine Standardroute installiert, sodass Antworten an Ihre Workstation jetzt durch den Tunnel verlassen, wo die Adresse Ihrer Workstation nicht routbar ist. Das Interessante daran ist, dass dieses Ergebnis vorhersehbar war, und die Lösung ist eine Route, die vor dem Start des Clients geschrieben wird. Nehmen Sie einen Server mit einer einzigen Netzwerkkarte an, ein Gateway von 192.0.2.254 und einen Administrator, der sich von 203.0.113.9 aus verbindet.

Notieren Sie den Pfad, bevor Sie starten

ip route show default nennt das aktuelle Gateway und Interface, während ip route get 203.0.113.9 zeigt, welches Interface und welche Quelladresse der Kernel für Ihre Sitzung verwenden würde. Behalten Sie beide Ausgaben. Nachdem der Tunnel hochkommt, sollten diese beiden Befehle noch den physischen Pfad beschreiben, und wenn sie stattdessen den Tunnel beschreiben, lebt die Sitzung bereits auf geborgter Zeit.

Es zählt die bestehende Verbindung, validieren Sie also nicht nur mit einer neuen Anmeldung. Eine neue Sitzung kann kurzzeitig durch Zustand gelingen, den die alte nicht mehr hat.

Fixieren Sie die Adresse in der Konfiguration des Clients selbst

Eine von Hand hinzugefügte Route verschwindet beim Neustart und läuft mit den eigenen Tabellenaktualisierungen des Clients um die Wette, legen Sie die Ausnahme also dorthin, wo die Tabelle verwaltet wird. Unter OpenVPN löst das Schlüsselwort net_gateway zum Gateway auf, das vor dem Tunnel existierte, sodass route 203.0.113.9 255.255.255.255 net_gateway genau eine Adresse außerhalb hält. WireGuard braucht einen anderen Ansatz, weil wg-quick die Routen selbst verwaltet: Setzen Sie Table = off und fügen Sie die Ausnahme in PostUp hinzu, mit einem passenden PostDown, das sie entfernt. Beide Formen drücken dieselbe Absicht aus, und beide beschränken die Ausnahme auf eine Adresse, statt den Tunnel für alles zu schwächen.

Für IPv6 nimmt dieselbe Idee ein Einzelhost-Präfix, und der Fall des gekapselten Transports ist es wert, gemerkt zu werden: Lebt die äußere Verbindung des Tunnels selbst an einer festen Adresse, muss diese Adresse außerhalb des Tunnels bleiben, den sie trägt, sonst routet der Client seinen eigenen Transport in sich selbst.

Oder nehmen Sie die Haupttabelle aus der Gleichung

Wenn mehrere Dienste auf dem Host ihren normalen Pfad behalten müssen, hören Sie auf, die Haupttabelle zu bearbeiten, und geben Sie dem Client seine eigene. Ein Netzwerk-Namensraum mit einem veth-Paar erledigt das sauber: Die Standardroute des Clients lebt in einem anderen Stack, und nur darin gestartete Prozesse nutzen den Tunnel. Policy-Routing erreicht für ein Ziel einen ähnlichen Ort, indem es passenden Verkehr in eine eigene Tabelle schickt, deren Standard noch auf das physische Gateway zeigt. Beide Ansätze lassen die Haupttabelle des Hosts ohne neue Standardroute, und genau diese Eigenschaft hält SSH antwortend.

Beides ist mehr Maschinerie als eine einzelne Host-Route, und beides lohnt sich, wenn mehr als eine Sache auf der Kiste den Tunnel überleben muss.

Gehen Sie davon aus, dass die Fixierung scheitern kann

Eine Route, die an Ihre aktuelle öffentliche Adresse gebunden ist, bricht in dem Moment, in dem Ihr Anbieter sie neu zuweist. Ein entfernter Server braucht dann einen Pfad, der nicht von dieser Adresse abhängt: eine Konsole, ein zweites Management-Interface oder einen Jump-Host, der außerhalb des Tunnels bleibt.

Zwei Schutzmaßnahmen kosten zehn Minuten. Ein Watchdog, der den Client stoppt, wenn innerhalb weniger Minuten keine Bestätigungsanmeldung erscheint, verwandelt eine Aussperrung in eine Verzögerung, und eine zweite SSH-Sitzung, die während der Änderung offen gehalten wird, beweist, dass die Ausnahme funktioniert, während der Tunnel steht. Keepalives allein helfen hier nicht, weil der Pfad weg ist statt untätig; sie machen den Tod nur leichter bemerkbar.

Prüfen Sie in der Reihenfolge, auf die es ankommt

Verbinden Sie den Tunnel, bestätigen Sie, dass die Route zu Ihrer Adresse noch über das physische Gateway verlässt, und öffnen Sie dann eine neue Sitzung. Wenn die neue Sitzung funktioniert und die alte trotzdem stirbt, ist die Ursache Connection Tracking oder eine zustandsbehaftete Firewall und nicht das Routing, was eine andere Lösung ist.

Schreiben Sie die fixierte Adresse und den Befehl, der sie bewiesen hat, in den Änderungsdatensatz. Die nächste Person, die auf diesem Host einen Client startet, braucht beides, und die Adresse kann sich bis dahin geändert haben.