Een bestaande HTTP- of SOCKS-proxy bereiken via SSH
Bereik een externe loopback HTTP- of SOCKS-proxy via SSH zonder de listener openbaar te maken.
Als relay.example.net al SOCKS draait op zijn eigen 127.0.0.1:1080, stuur de toegang door in plaats van die listener openbaar te maken:
ssh -N -L 127.0.0.1:1081:127.0.0.1:1080 [email protected]| Eindpunt | Rol |
|---|---|
Laptop 127.0.0.1:1081 | Het SOCKS-adres dat in de laptopapplicatie moet worden geconfigureerd. |
Relay 127.0.0.1:1080 | De bestaande proxy die vanaf de SSH-serverzijde wordt bereikt. |
De syntaxis voor lokale doorsturing wijst de vaste bestemming aan de serverzijde toe. Een HTTP-proxy op de externe loopback-poort 3128 of een intranet-eindpunt zoals proxy.internal.example:8080 werkt volgens hetzelfde principe. Configureer de client voor dat bestaande HTTP-protocol en het account; het door SSH heen voeren maakt geen SOCKS of een TLS-geschikte HTTPS-listener.
De bestaande dienst kiest nog steeds ondersteunde protocolversies, authenticatie, bestemmingen en de uiteindelijke uitgang. Als een ander SSH-proces die externe proxy heeft gemaakt, moeten beide processen in leven blijven. Een route laptop→relay→gateway laat de website de laatste uitgaande verbinding zien, niet een identiteit die door de lokale poort 1081 wordt toegewezen.
Houd de binding van de laptop uitdrukkelijk lokaal. Bredere blootstelling verandert wie de dienst kan bereiken, en SSH-login voegt geen SOCKS-wachtwoord toe aan de listener. Controleer bij weigering de listener van de laptop, het SSH-transport en de externe proxy als afzonderlijke fasen.