Wie eine lokale SSH-Weiterleitung eine TCP-OpenVPN-Sitzung trägt

Hier stapeln sich drei Transporte, und jeder hat seine eigene Rahmung. Die VPN-Nutzlast reist in einer TLS-Sitzung, diese TLS-Sitzung reist in einer TCP-Verbindung zu einem Loopback-Port, und die Bytes dieser Verbindung reisen in SSH zu einem Relay-Host, der die eigentliche TCP-Verbindung zum VPN-Listener öffnet. Nichts an der Anordnung ändert, was OpenVPN authentifiziert, und nichts daran macht einen UDP-Listener über TCP erreichbar. Lesen Sie den Rest als Beschreibung des Bytepfads, nicht als Rezept zum Umgehen einer Netzwerkkontrolle.

Was die lokale Weiterleitung tatsächlich bewegt

Der SSH-Client lauscht auf einem lokalen Port. Wenn ein lokaler Prozess sich verbindet, packt der Client die Bytes in seinen verschlüsselten Kanal, und die Serverseite öffnet eine neue TCP-Verbindung zum im Weiterleitungsauftrag genannten Ziel.

Dieses Ziel löst das Relay auf, nicht Ihr Rechner, weshalb ein Name, der nur im entfernten Netz existiert, weiterhin funktioniert. Das bedeutet auch, dass das Relay den VPN-Listener erreichen und einen Rückweg dorthin haben muss. Ein Name, der auf Ihrem Laptop aufgelöst wird, sagt nichts darüber aus, was das Relay sieht.

Das Starten der SSH-Sitzung beweist nur, dass das Relay erreichbar und authentifiziert ist. Es sagt nichts darüber aus, ob der weitere Listener läuft, ob eine Firewall zwischen Relay und Listener die Verbindung annimmt oder ob das VPN Ihr Profil akzeptiert.

Richten Sie den Client auf den lokalen Listener

Ein genanntes Beispiel: Das Relay erreicht einen TCP-Listener unter gw.internal.example:443, und ein hoher lokaler Port legt diesen Pfad nur für diesen Rechner offen.

ssh -N -L 127.0.0.1:24011:gw.internal.example:443 [email protected]

Das OpenSSH-Handbuch beschreibt die lokale Weiterleitung als lokale Annahme von TCP-Verbindungen und Öffnen der weiteren Verbindung von der entfernten Seite. Binden Sie den Listener an Loopback statt an alle Schnittstellen, denn eine aus dem Netz erreichbare Weiterleitung ist ein offenes Relay mit Ihrem Namen. Eine Wildcard-Bindung legt den Port auch für jedes andere lokale Konto auf einem gemeinsam genutzten Rechner offen.

Setzen Sie dann den VPN-Client in seinen TCP-Modus und richten Sie ihn auf 127.0.0.1:24011. Nutzt das Profil UDP, kann dieses Design nicht helfen: Die Weiterleitung trägt einen Bytestrom, und es gibt keinen Datagrammpfad hindurch.

Halten Sie die beiden Authentifizierungen getrennt

SSH authentifiziert den Relay-Host. OpenVPN authentifiziert weiterhin den VPN-Peer, und das Loopback-Ziel ändert diese Anforderung nicht. Die Zertifikatsprüfungen abzuschalten, weil der Socket nun auf localhost zeigt, ist die schlechteste Abkürzung in diesem Design. Sie verwandelt eine Transportanordnung in eine Vertrauensanordnung, und niemand hat der zweiten zugestimmt.

Halten Sie den Vertrauensanker des Profils, die Serverrollenprüfung und die Namensprüfung intakt. Wenn Ihr Client den Servernamen mit der angewählten Adresse vergleicht, braucht Loopback möglicherweise eine ausdrückliche Namenseinstellung statt einer abgeschalteten Prüfung, und die Profildokumentation ist der Ort, um zu bestätigen, welches Feld verglichen wird.

Behandeln Sie das Relay als zweiten Beteiligten in der Vertrauensgeschichte: Sein Administrator sieht Verbindungsmetadaten und kann die Weiterleitung umleiten, wenn die Konfiguration geändert wird. Die Anordnung braucht die Zustimmung sowohl des Relays als auch des VPN-Diensteigentümers, nicht nur dessen, der sie heute braucht.

Bauen Sie keine Schleife unter dem Tunnel

Sobald das VPN Routen installiert, braucht die SSH-Verbindung, die es trägt, weiterhin einen Pfad zum Relay, der nicht durch den Tunnel läuft. Wandert die Standardroute zum VPN und ist das Relay nur durch denselben Tunnel erreichbar, bricht der Transport zusammen und das VPN geht mit. Der Fehler sieht wie ein abgebrochener Tunnel aus und nicht wie ein Routingfehler, weshalb er falsch diagnostiziert wird.

Die übliche Lösung ist eine Host-Route zur Relay-Adresse, die vor dem Hochfahren des Tunnels an die physische Schnittstelle gebunden wird, plus eine Prüfung, dass die Route einen Reconnect übersteht. Prüfen Sie sie mit einer Routensuche für die Relay-Adresse, statt anzunehmen, die Reihenfolge sei richtig gewesen.

Erwarten Sie außerdem, dass dieser Stapel langsamer und fragiler als eine direkte Verbindung ist, weil es nun zwei geordnete Transporte und einen weiteren Endpunkt zu pflegen gibt. Es ist ein Weg, eine Netzgrenze zu überqueren, keine Leistungstechnik.

Schließen Sie den Listener, wenn Sie fertig sind

Beenden Sie die SSH-Sitzung, wenn der Tunnel nicht mehr gebraucht wird, und bestätigen Sie, dass der lokale Port freigegeben ist. Eine vergessene Weiterleitung hält einen authentifizierten Pfad auf einem Rechner offen, der geteilt sein kann.

Prüfen Sie auch die erlaubten Weiterleitungsziele des Relays, denn eine großzügige Konfiguration macht jedes kompromittierte Konto zu einem allgemeinen Drehpunkt. Notieren Sie Port, Relay und Ziel zusammen, damit die nächste Person erkennen kann, wofür die Weiterleitung war und ob sie noch genehmigt ist.