Einen vorhandenen HTTP- oder SOCKS-Proxy über SSH erreichen
Erreichen Sie einen entfernten Loopback-HTTP- oder SOCKS-Proxy über SSH, ohne dessen Listener öffentlich bereitzustellen.
Wenn relay.example.net bereits SOCKS auf seinem eigenen 127.0.0.1:1080 ausführt, leiten Sie den Zugriff weiter, statt diesen Listener öffentlich bereitzustellen:
ssh -N -L 127.0.0.1:1081:127.0.0.1:1080 [email protected]| Endpunkt | Rolle |
|---|---|
Laptop 127.0.0.1:1081 | Die SOCKS-Adresse, die in der Anwendung auf dem Laptop konfiguriert wird. |
Relay 127.0.0.1:1080 | Der vorhandene Proxy, der von der SSH-Serverseite aus erreicht wird. |
Die Syntax für lokale Weiterleitung weist das feste Ziel der Serverseite zu. Ein HTTP-Proxy am entfernten Loopback-Port 3128 oder ein Intranet-Endpunkt wie proxy.internal.example:8080 funktioniert nach demselben Prinzip. Konfigurieren Sie den Client für dieses vorhandene HTTP-Protokoll und das Konto; die Übertragung über SSH erzeugt weder SOCKS noch einen TLS-fähigen HTTPS-Listener.
Der vorhandene Dienst wählt weiterhin unterstützte Protokollversionen, Authentifizierung, Ziele und den endgültigen Ausgang. Wenn ein anderer SSH-Prozess diesen entfernten Proxy erstellt hat, müssen beide Prozesse am Leben bleiben. Eine Route Laptop→Relay→Gateway lässt die Website die letzte ausgehende Verbindung sehen, nicht eine vom lokalen Port 1081 zugewiesene Identität.
Halten Sie die Bindung des Laptops ausdrücklich lokal. Eine breitere Bereitstellung ändert, wer den Dienst erreichen kann, und die SSH-Anmeldung fügt dem Listener kein SOCKS-Passwort hinzu. Prüfen Sie bei einer Ablehnung den Listener des Laptops, den SSH-Transport und den entfernten Proxy als getrennte Stufen.