SSH bidez birbidalitako portua ez da beti SOCKS proxy bat
Bereizi SSH tokiko birbidalketa finkoa SOCKS entzule dinamikotik aplikazio bat konfiguratu aurretik.
SSH tunel bat sortzen duzu, 127.0.0.1 eta bere portua nabigatzailearen proxy ezarpenetan sartzen dituzu, eta ezer ez da kargatzen. Entzulea primeran aritu liteke lanean. Baliteke trafiko mota okerraren zain egotea besterik ez.
| Birbidalketa | Zer bidaltzen du tokiko aplikazioak | Helmuga aukeratzea |
|---|---|---|
-L | Helburuko zerbitzuaren ohiko protokoloa | SSH komandoan finkatuta |
-D | SOCKS negoziazioa, gero aplikazioaren trafikoa | SOCKS bezeroak eskatuta |
Web zerbitzari bakarrerako, hau birbidalketa finkoa da:
ssh -N -L 127.0.0.1:9080:web.example.com:80 [email protected]Bisitatu http://127.0.0.1:9080/ webgune gisa. Ez etiketatu 9080 portua SOCKS gisa: komandoan izendatutako web zerbitzari bakarrari bidaltzen dizkio byteak. Beste ostalari-izen baten pean gune bat irekitzeak bere ostalaritza birtualean, birbideratzeetan edo cookieetan ere eragin dezake.
SOCKS entzule baterako, forma aldatzen da:
ssh -N -D 127.0.0.1:1080 [email protected]Konfiguratu aplikazioa 127.0.0.1:1080 helbidean SOCKS erabiltzeko. Helbide hori zuzenean nabigatzailearen helbide-barran sartzeak web eskaera bat SOCKS entzulera bidaltzen du, protokolo desadostasun bat gehiago.
OpenSSH eskuliburuak bi formak dokumentatzen ditu. Salbuespen erabilgarri bat dago: lehendik dagoen HTTP proxy bat -L erabiliz birbidaltzeak HTTP proxy protokoloa hitz egiten duen tokiko portu bat sortzen du, zeren bere helmuga finkoa bera HTTP proxy bat baita. Urruneko muturreko zerbitzuak zehazten du zer dagokion birbidalketa finkoari. Lehendik dagoen proxy bat SSH bidez birbidaltzea proxy horren protokoloa eta kontua mantentzen ditu.