In besteande HTTP- of SOCKS-proxy berikke fia SSH
Berik in remote loopback HTTP- of SOCKS-proxy fia SSH sûnder de listener iepenbier bleat te stellen.
As relay.example.net al SOCKS draait op syn eigen 127.0.0.1:1080, stjoer tagong troch yn stee fan dy listener iepenbier bleat te stellen:
ssh -N -L 127.0.0.1:1081:127.0.0.1:1080 [email protected]| Einpunt | Rol |
|---|---|
Laptop 127.0.0.1:1081 | It SOCKS-adres dat yn 'e laptop-app konfigurearre wurde moat. |
Relay 127.0.0.1:1080 | De besteande proxy dy't fan 'e SSH-serverkant berikt wurdt. |
De syntaksis foar lokale trochstjoering jout it fêste bestimming oan 'e serverkant. In HTTP-proxy op 'e remote loopback-poarte 3128 of in intranet-einpunt lykas proxy.internal.example:8080 wurket neffens itselde prinsipe. Konfigurearje de klant foar dat besteande HTTP-protokol en akkount; it troch SSH stjoeren makket gjin SOCKS of in TLS-oanmakke HTTPS-listener.
De besteande tsjinst kiest noch altyd stipe protokolferzjes, autentikaasje, bestimmingen en de definitive útgong. As in oar SSH-proses dy remote proxy makke hat, moatte beide prosessen libben bliuwe. In rûte laptop→relay→gateway lit de webside de lêste útgeande ferbining sjen, net in identiteit tawiisd troch lokale poarte 1081.
Hâld de laptop-bining eksplisyt lokaal. Wider bleatstelling feroaret wa't de tsjinst berikke kin, en SSH-ynloggen foeget gjin SOCKS-wachtwurd ta oan 'e listener. Kontrolearje by wegering de laptop-listener, it SSH-transport en de remote proxy as aparte stadia.