Një port i përcjellë përmes SSH nuk është gjithmonë një proxy SOCKS
Dalloni një përcjellje lokale fikse SSH nga një dëgjues dinamik SOCKS përpara se të konfiguroni një aplikacion.
Krijoni një tunel SSH, vendosni 127.0.0.1 dhe portën e tij në cilësimet e proxy-t të shfletuesit, dhe asgjë nuk ngarkohet. Dëgjuesi mund të funksionojë në mënyrë të përsosur. Ndoshta thjesht po pret llojin e gabuar të trafikut.
| Përcjellje | Çfarë dërgon aplikacioni lokal | Zgjedhja e destinacionit |
|---|---|---|
-L | Protokolli i zakonshëm i shërbimit të synuar | Fiksuar në komandën SSH |
-D | Një negociatë SOCKS, pastaj trafiku i aplikacionit | Kërkuar nga klienti SOCKS |
Për një server të vetëm web, kjo është një përcjellje fikse:
ssh -N -L 127.0.0.1:9080:web.example.com:80 [email protected]Vizitoni http://127.0.0.1:9080/ si një faqe web. Mos e etiketoni portën 9080 si SOCKS: ajo përcjell bajt te serveri i vetëm web i emërtuar në komandë. Hapja e një faqeje nën një emër tjetër hosti mund të ndikojë gjithashtu në hostingun e saj virtual, ridrejtimet ose cookie-t.
Për një dëgjues SOCKS, forma ndryshon:
ssh -N -D 127.0.0.1:1080 [email protected]Konfigurojeni aplikacionin të përdorë SOCKS në 127.0.0.1:1080. Futja e asaj adrese drejtpërdrejt në shiritin e adresave të shfletuesit dërgon një kërkesë web te një dëgjues SOCKS, një tjetër mospërputhje protokolli.
Manual i OpenSSH dokumenton të dyja format. Ekziston një përjashtim i dobishëm: përcjellja e një proxy HTTP ekzistues me -L prodhon një port lokal që flet protokollin e proxy-t HTTP, sepse destinacioni i tij fiks është vetë një proxy HTTP. Shërbimi në skajin e largët përcakton çfarë i takon një përcjelljeje fikse. Përcjellja e një proxy ekzistues përmes SSH ruan protokollin dhe llogarinë e atij proxy.