Een via SSH doorgestuurde poort is niet altijd een SOCKS-proxy
Onderscheid een vaste lokale SSH-doorstuurd van een dynamische SOCKS-listener voordat u een toepassing configureert.
U maakt een SSH-tunnel, voert 127.0.0.1 en de poort ervan in de proxyinstellingen van de browser in, en er wordt niets geladen. De listener werkt misschien prima. Misschien wacht hij gewoon op het verkeerde soort verkeer.
| Doorsturen | Wat de lokale toepassing verstuurt | Keuze van bestemming |
|---|---|---|
-L | Het gewone protocol van de doeldienst | Vastgelegd in het SSH-commando |
-D | Een SOCKS-onderhandeling, daarna toepassingsverkeer | Aangevraagd door de SOCKS-client |
Voor één webserver is dit een vaste doorstuurd:
ssh -N -L 127.0.0.1:9080:web.example.com:80 [email protected]Bezoek http://127.0.0.1:9080/ als website. Label poort 9080 niet als SOCKS: hij stuurt bytes door naar de ene webserver die in het commando wordt genoemd. Een site onder een andere hostnaam openen kan ook invloed hebben op de virtuele hosting, de omleidingen of de cookies ervan.
Voor een SOCKS-listener verandert de vorm:
ssh -N -D 127.0.0.1:1080 [email protected]Configureer de toepassing om SOCKS te gebruiken op 127.0.0.1:1080. Dat adres rechtstreeks in de adresbalk van de browser typen, stuurt een webverzoek naar een SOCKS-listener, weer een protocolfout.
OpenSSH-handleiding documenteert beide vormen. Er is een nuttige uitzondering: een bestaande HTTP-proxy doorsturen met -L levert een lokale poort op die HTTP-proxyprotocol spreekt, omdat de vaste bestemming zelf een HTTP-proxy is. De dienst aan de andere kant bepaalt wat bij een vaste doorstuurd hoort. Een bestaande proxy via SSH doorsturen behoudt het protocol en het account van die proxy.