Einem entfernten Pi über Ihren SSH-Client einen SOCKS-Proxy geben

Eine entfernte dynamische Weiterleitung legt den SOCKS-Listener auf dem Pi ab und baut die weitere Verbindung über den freigegebenen VPN-Pfad Ihres Laptops auf. Kein zweiter SSH-Server.

Sie nehmen an, ein SOCKS-Proxy müsse dort laufen, wo der Netzwerkzugang bereits besteht. OpenSSH kann den Listener ganz woanders platzieren. Eine entfernte dynamische Weiterleitung öffnet den SOCKS-Port auf einem entfernten Host und führt jede Verbindung von Ihrem lokalen SSH-Client aus, der den freigegebenen VPN-Pfad Ihres Laptops trägt. Der Pi bekommt einen begrenzten Proxy; er erbt weder Ihren Tunnel noch Ihre Rechte.

Listener und die Seite, von der die Verbindung ausgeht, können sich unterscheiden

Ein gewöhnliches ssh -D 1080 startet den Listener auf Ihrem eigenen Rechner und schickt Verbindungen von dort hinaus. Eine entfernte dynamische Weiterleitung kehrt das um: Der Listener erscheint auf dem entfernten Host, und jede Verbindung, die er annimmt, wird von der lokalen Seite aus geöffnet. Das Handbuch des OpenSSH-Clients dokumentiert -R ohne festes Ziel genau als diese SOCKS4/5-Anordnung.

Ein unterstützter Befehl vom Laptop sieht so aus, wobei Konto, Hosts und Port als Platzhalter behandelt werden:

ssh -NT -S none -o ExitOnForwardFailure=yes \
  -o PermitRemoteOpen=app.corp.example:443 \
  -R 1080 [email protected]

Drei Details leisten dort nützliche Arbeit. -S none hält die Sitzung von einem gemeinsamen Control-Master fern, ExitOnForwardFailure scheitert schnell, statt Sie mit einer halb offenen Sitzung zurückzulassen, und PermitRemoteOpen begrenzt, was der entfernte Listener erreichen darf. Verwenden Sie ein autorisiertes Pi-Konto und prüfen Sie den Hostschlüssel, bevor Sie irgendetwas davon hinzufügen.

Was der entfernte Listener wirklich preisgibt

Prüfen Sie die Weiterleitungsrichtlinie des Servers, bevor Sie sich auf den Listener verlassen. Mit GatewayPorts no bleibt die entfernte Weiterleitung an Loopback gebunden, und das ist die Exposition, die Sie wollen. Ein Server, der auf Wildcard-Weiterleitung gezwungen ist, veröffentlicht denselben Port auf jeder Schnittstelle, was einen persönlichen Proxy zu etwas macht, das das lokale Netz erreichen kann.

Loopback ist auch keine Grenze pro Benutzer. Ein anderer Prozess auf dem Pi kann sich mit 127.0.0.1:1080 verbinden, wenn er den Port kennt, also gehören die lokalen Konten des Pi und alles, was darauf läuft, zu Ihrem Zugangsdesign. Das ist ein Grund, die Zielliste eng zu halten, kein Grund, die Richtlinienprüfung zu überspringen.

Halten Sie das erlaubte Ziel spezifisch für die Anwendung, die Sie erreichen wollen. Es durch uneingeschränkte Weiterleitung zu ersetzen, damit ein unbeteiligtes Programm funktioniert, verbreitert den Pfad weit über das Problem hinaus, mit dem Sie begonnen haben. Eine Zielliste hält außerdem fest, wofür die Sitzung war, was jedem hilft, der sie später prüft. Schreiben Sie sie neben das verwendete Konto.

Schicken Sie eine Anwendung durch den Proxy

Ein proxyfähiger Client auf dem Pi kann die Anfrage dann stellen. Das Präfix socks5h übergibt den Zielnamen an den Proxy, sodass Namensauflösung und Verbindung beide auf der Laptopsseite stattfinden, und es passt zum benannten Ziel in PermitRemoteOpen:

curl --proxy socks5h://127.0.0.1:1080 \
  --noproxy '' https://app.corp.example/

Behalten Sie die normale Zertifikatsprüfung und die eigene Authentifizierung der Anwendung bei. Der Proxy ändert, wo die TCP-Verbindung aufgebaut wird; er macht einen nicht authentifizierten Dienst nicht sicher und verwandelt einen selbstsignierten Endpunkt nicht in einen vertrauenswürdigen.

Der Laptop braucht weiterhin seine eigene Route und Resolver-Zugang sowohl zum SSH-Server als auch zur Anwendung. Der Verkehr seines SSH-Clients muss durch die freigegebene VPN-Richtlinie ausgewählt werden, und eine Split-Tunnel-Ausnahme kann diesen Verkehr über einen anderen Pfad schicken als den getesteten.

Beweisen Sie den Pfad und schließen Sie ihn

Bestätigen Sie, dass der Listener dort existiert, wo Sie ihn erwarten, und dass nur das beabsichtigte Ziel antwortet:

$ ss -ltnp | grep 1080
LISTEN 0 128 127.0.0.1:1080 0.0.0.0:*
$ curl -sS -o /dev/null -w '%{http_code}\n' \
    --proxy socks5h://127.0.0.1:1080 https://app.corp.example/

ExitOnForwardFailure kann beweisen, dass die Weiterleitung aufgebaut wurde, und kann dennoch nicht bescheinigen, dass die Anmeldung in der Anwendung dahinter gelingt. Testen Sie die Anwendung, nicht nur den Port. Ein Listener, der annimmt und dann jede Anfrage scheitern lässt, bedeutet meist, dass der Zielname oder die Route des Laptops falsch ist, nicht dass der Tunnel versagt hat.

Diese Anordnung transportiert nur TCP. UDP, ICMP und Programme, die Proxy-Einstellungen ignorieren, bleiben außerhalb, und die Weiterleitung endet in dem Moment, in dem die SSH-Sitzung endet. Beenden Sie diese Sitzung, wenn Sie fertig sind, und entfernen Sie die Proxy-Einstellung, die Sie der Anwendung hinzugefügt haben.

Für dauerhaften Zugang nutzen Sie stattdessen die unterstützte Registrierung des Netzwerkeigentümers oder ein verwaltetes Gateway. Ein Reverse-Proxy ist das falsche Werkzeug, um Geräte- oder Ressourcenbeschränkungen einer VPN zu umgehen; innerhalb dieser Beschränkungen eingesetzt, ist er schlicht ein autorisierter Anwendungspfad mit ausdrücklichen Grenzen.

Ähnliche Artikel