Ang port na ipinasa sa SSH ay hindi laging SOCKS proxy
Ihiwalay ang nakapirming lokal na pagpasa ng SSH mula sa dinamikong tagapakinig ng SOCKS bago i-configure ang isang aplikasyon.
Gumagawa ka ng SSH tunnel, inilalagay ang 127.0.0.1 at ang port nito sa mga setting ng proxy ng browser, at walang naglo-load. Maaaring gumagana nang maayos ang tagapakinig. Maaaring hinihintay lamang nito ang maling uri ng trapiko.
| Pagpasa | Ano ang ipinapadala ng lokal na aplikasyon | Pagpili ng destinasyon |
|---|---|---|
-L | Ang karaniwang protocol ng target na serbisyo | Nakapirmi sa utos ng SSH |
-D | Isang pakikipag-usap sa SOCKS, pagkatapos ang trapiko ng aplikasyon | Hiniling ng kliyente ng SOCKS |
Para sa isang web server, ito ay isang nakapirming pagpasa:
ssh -N -L 127.0.0.1:9080:web.example.com:80 [email protected]Bisitahin ang http://127.0.0.1:9080/ bilang isang website. Huwag lagyan ng label na SOCKS ang port 9080: ipinapasa nito ang mga byte sa nag-iisang web server na pinangalanan sa utos. Ang pagbubukas ng site sa ilalim ng ibang hostname ay maaari ring makaapekto sa virtual hosting, mga redirect, o mga cookie nito.
Para sa isang tagapakinig ng SOCKS, nagbabago ang hugis:
ssh -N -D 127.0.0.1:1080 [email protected]I-configure ang aplikasyon na gumamit ng SOCKS sa 127.0.0.1:1080. Ang paglalagay ng address na iyon nang direkta sa address bar ng browser ay nagpapadala ng web request sa isang tagapakinig ng SOCKS, isa pang hindi pagkakatugma ng protocol.
Manwal ng OpenSSH ang nagdodokumento sa dalawang anyo. May isang kapaki-pakinabang na eksepsiyon: ang pagpasa sa isang umiiral na HTTP proxy gamit ang -L ay gumagawa ng lokal na port na nagsasalita ng protocol ng HTTP proxy, dahil ang nakapirming destinasyon nito ay isa ring HTTP proxy. Ang serbisyo sa dulong bahagi ang nagtatakda kung ano ang nababagay sa isang nakapirming pagpasa. Pagpasa sa isang umiiral na proxy sa pamamagitan ng SSH ay nagpapanatili sa protocol at account ng proxy na iyon.