'n SSH-aangestuurde poort is nie altyd 'n SOCKS-proxy nie
Onderskei 'n vaste plaaslike SSH-aanstuur van 'n dinamiese SOCKS-luisteraar voordat jy 'n toepassing opstel.
Jy maak 'n SSH-tonnel, sit 127.0.0.1 en sy poort in 'n blaaier se proxy-instellings, en niks laai nie. Die luisteraar werk dalk heeltemal reg. Dit wag dalk net op die verkeerde soort verkeer.
| Aanstuur | Wat die plaaslike toepassing stuur | Keuse van bestemming |
|---|---|---|
-L | Die teikendiens se gewone protokol | Vasgelê in die SSH-opdrag |
-D | 'n SOCKS-onderhandeling, dan toepassingverkeer | Deur die SOCKS-kliënt aangevra |
Vir een webbediening is dit 'n vaste aanstuur:
ssh -N -L 127.0.0.1:9080:web.example.com:80 [email protected]Besoek http://127.0.0.1:9080/ as 'n webwerf. Moenie poort 9080 as SOCKS benoem nie: dit stuur grepe na die een webbediening wat in die opdrag genoem word. Om 'n werf onder 'n ander gasheernaam oop te maak, kan ook sy virtuele gasheer, herleidings of koekies beïnvloed.
Vir 'n SOCKS-luisteraar verander die vorm:
ssh -N -D 127.0.0.1:1080 [email protected]Stel die toepassing in om SOCKS by 127.0.0.1:1080 te gebruik. Om daardie adres direk in die blaaier se adresbalk te tik, stuur 'n webversoek na 'n SOCKS-luisteraar, nog 'n protokolwanpassing.
Die OpenSSH-handleiding dokumenteer albei vorme. Daar is 'n nuttige uitsondering: om 'n bestaande HTTP-proxy met -L aan te stuur lewer 'n plaaslike poort wat HTTP-proxyprotokol praat, want sy vaste bestemming is self 'n HTTP-proxy. Die diens aan die ander kant bepaal wat op 'n vaste aanstuur hoort. Om 'n bestaande proxy deur SSH aan te stuur behou daardie proxy se protokol en rekening.