Ein per SSH weitergeleiteter Port ist nicht immer ein SOCKS-Proxy
Unterscheiden Sie eine feste lokale SSH-Weiterleitung von einem dynamischen SOCKS-Listener, bevor Sie eine Anwendung konfigurieren.
Sie erstellen einen SSH-Tunnel, tragen 127.0.0.1 und seinen Port in die Proxy-Einstellungen des Browsers ein, und nichts lädt. Der Listener arbeitet möglicherweise einwandfrei. Vielleicht wartet er nur auf die falsche Art von Datenverkehr.
| Weiterleitung | Was die lokale Anwendung sendet | Wahl des Ziels |
|---|---|---|
-L | Das übliche Protokoll des Zieldienstes | Im SSH-Befehl festgelegt |
-D | Eine SOCKS-Aushandlung, dann Anwendungsdatenverkehr | Vom SOCKS-Client angefordert |
Für einen einzelnen Webserver ist dies eine feste Weiterleitung:
ssh -N -L 127.0.0.1:9080:web.example.com:80 [email protected]Rufen Sie http://127.0.0.1:9080/ als Website auf. Bezeichnen Sie Port 9080 nicht als SOCKS: Er leitet Bytes an den einen im Befehl genannten Webserver weiter. Eine Website unter einem anderen Hostnamen zu öffnen, kann auch ihr virtuelles Hosting, ihre Weiterleitungen oder Cookies beeinflussen.
Für einen SOCKS-Listener ändert sich die Form:
ssh -N -D 127.0.0.1:1080 [email protected]Konfigurieren Sie die Anwendung so, dass sie SOCKS unter 127.0.0.1:1080 verwendet. Diese Adresse direkt in die Adressleiste des Browsers einzugeben, sendet eine Webanfrage an einen SOCKS-Listener, ein weiterer Protokollkonflikt.
OpenSSH-Handbuch dokumentiert beide Formen. Es gibt eine nützliche Ausnahme: Einen vorhandenen HTTP-Proxy mit -L weiterzuleiten erzeugt einen lokalen Port, der HTTP-Proxy-Protokoll spricht, weil sein festes Ziel selbst ein HTTP-Proxy ist. Der Dienst am fernen Ende bestimmt, was zu einer festen Weiterleitung gehört. Einen vorhandenen Proxy über SSH weiterleiten behält Protokoll und Konto dieses Proxys bei.