Dynamische SSH-Weiterleitung als SOCKS-Proxy über Ihr VPN

Eine Anwendung, die nur SOCKS spricht, hat in einem einfachen VPN kein Gegenüber, weil der Tunnel Pakete trägt und die App einen Proxy-Endpunkt will. OpenSSH kann diesen Endpunkt bereitstellen, wenn der Zugangsinhaber es erlaubt, denn dynamische Weiterleitung macht aus einer SSH-Sitzung einen lokalen Proxy. Danach sind zwei Sprünge auseinanderzuhalten: der Tunnel, der den SSH-Host erreicht, und die Verbindung, die dieser Host weiter aufbaut. Ihre Trennung erklärt sowohl, warum die Anordnung funktioniert, als auch, was sie nie leisten wird.

Was der SSH-Listener wird und was nicht

Dynamische Weiterleitung bringt den SSH-Client dazu, lokal zu lauschen und mit allem, was sich verbindet, SOCKS4 oder SOCKS5 zu sprechen. Jede Anfrage nennt ein Ziel, und der SSH-Server öffnet die Weiterverbindung, weshalb die Zielsuche auf der Gegenseite stattfinden kann. Das ist TCP-Weiterleitung auf Anwendungsebene, kein VPN für das ganze Gerät. Sie überträgt keine UDP-Assoziation, kein ICMP und nichts für Anwendungen, die Proxy-Einstellungen völlig ignorieren. Auch der Sprung vom SSH-Server zur Anwendung liegt nicht in Ihrem Tunnel, was zählt, wenn das Ziel Verkehr nur aus bekannten Netzen annimmt.

Die Voraussetzungen sind real: eine Route zum SSH-Host, ein autorisiertes Konto, ein geprüfter Hostschlüssel des Servers und die Erlaubnis weiterzuleiten. Keine davon schafft der Proxy, und die letzte fehlt meist zuerst. Prüfen Sie alle vier, bevor Sie irgendetwas anderes debuggen, denn vom Client aus sieht der Fehler gleich aus, welche auch immer fehlt.

Starten Sie ihn auf Loopback mit einem ausdrücklichen Port

Wählen Sie einen ungenutzten lokalen Port und binden Sie ihn ausdrücklich an Loopback, statt die Adresse wegzulassen. Die drei Optionen unten gibt es jeweils aus einem Grund.

ssh -D 127.0.0.1:1080 -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
  [email protected]

-N überspringt den entfernten Befehl und -T überspringt das Pseudoterminal, sodass die Sitzung nur zum Weiterleiten existiert. ExitOnForwardFailure lässt den Client beenden, wenn der Listener nicht angelegt werden kann, statt ohne die gewünschte Weiterleitung zu laufen. ControlPath=none hält die Sitzung aus einer bestehenden gemultiplexten Verbindung heraus, die eigene Weiterleitungen hinzufügen könnte. Loopback hält den Listener aus dem LAN, ist aber auf einem geteilten Rechner keine Autorisierungsgrenze, weil auch andere lokale Prozesse ihn erreichen können. Die OpenSSH-Client-Referenz dokumentiert alle diese Flags, und die Loopback-Warnung folgt daraus, was ein lauschender Socket ist.

Schicken Sie Namen durch den Proxy, nicht daran vorbei

Ein SOCKS5-Client kann das Ziel selbst auflösen oder den Proxy darum bitten, und diese Wahl entscheidet, welcher Resolver antwortet. Mit socks5h schickt curl den Hostnamen durch den Proxy, sodass die Auflösung auf dem SSH-Server geschieht. Mit einfachem socks5 löst der Laptop zuerst auf, und nur die Verbindung reist, was den Zweck still untergräbt, wenn der Name intern ist. Die Anfrage unten räumt außerdem die Ohne-Proxy-Liste, damit ein geerbter NO_PROXY-Wert sie nicht am Proxy vorbeileiten kann.

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

Zertifikatsprüfung und die eigene Anmeldung der Anwendung gelten weiter, denn der Proxy ersetzt keines von beiden. Zwei Auflösungen bleiben: Der Laptop muss den SSH-Host über den erlaubten VPN- und DNS-Weg erreichen, und der SSH-Server muss den Anwendungsnamen selbst auflösen. Die zweite lässt sich für sich testen, bevor irgendein Verkehr durch den Proxy läuft.

ssh [email protected] getent hosts app.corp.example

Beweisen Sie ein erlaubtes Ziel und beenden Sie dann die Sitzung

Testen Sie ein Ziel, das die Richtlinie erlaubt, und eines, das sie ablehnen sollte, denn eine funktionierende Weiterleitung beweist nur, dass der Listener arbeitet, und nichts weiter. Die Anwendung sieht die Quelladresse, die der SSH-Server wählt, und das ist nicht die Tunneladresse Ihres Laptops. Wo die Gegenseite Verbindungen nach Quelle protokolliert, ist dieser Unterschied das Erste, was zu prüfen ist, wenn eine Anfrage abgelehnt wird.

Beenden Sie die Sitzung über den Prozess, der sie besitzt, statt eine fremde Shell zu töten. Bestätigen Sie dann, dass der Listener weg ist, denn ein Port, der noch antwortet, ist eine Sitzung, die Sie nicht wirklich geschlossen haben. Entfernen Sie nur die Proxy-Einstellung, die diese Übung eingeführt hat, und lassen Sie den Rest der Anwendungskonfiguration in Ruhe. Ein unbeaufsichtigtes Terminal mit einer Weiterleitungsregel ist kein Dienst, und ein dauerhafter Proxy braucht einen genehmigten Lebenszyklus, kein vergessenes Fenster.

ss -ltn | grep 1080

Fehler, die diese Anordnung nicht beheben kann

Manche Symptome deuten direkt auf die Grenzen oben, und sie früh zu erkennen spart einen Nachmittag Proxy-Fehlersuche. Die Tabelle ordnet zu, was Sie sehen, dem zu, was es meist bedeutet. Alles in der letzten Spalte ist eine Designfrage, kein Konfigurationsfehler.

Die ersten drei Zeilen sind die, die Menschen falsch diagnostizieren, weil jede einen Verbindungsversuch erzeugt statt eines Fehlers über den Proxy selbst. Ein Name, der auf dem Laptop aufgelöst wird, sagt nichts über den Resolver des Servers, und der Fehler liest sich stattdessen als Zertifikats- oder Zeitüberschreitungsproblem. Anwendungen nur mit UDP stehen außerhalb des Designs, nicht darin kaputt, und keine zusätzliche ssh-Option ändert das. Die Browser-Zeile ist die übliche Erinnerung, dass Proxy-Einstellungen pro Anwendung gelten. Die letzte Zeile ist der Grund für die Abschlussprüfung: Ein Port, der noch lauscht, bedeutet, dass jetzt etwas anderes ihn besitzt.