SSH-plusendita pordo ne ĉiam estas SOCKS-prokurilo
Distingvu fiksan lokan SSH-plusendon disde dinamika SOCKS-auskultanto antaŭ ol agordi aplikaĵon.
Vi kreas SSH-tunelon, metas 127.0.0.1 kaj ĝian pordon en la prokurajn agordojn de retumilo, kaj nenio ŝargiĝas. La auskultanto eble perfekte funkcias. Ĝi eble simple atendas la malĝustan specon de trafiko.
| Plusendo | Kion la loka aplikaĵo sendas | Elekto de celo |
|---|---|---|
-L | La ordinara protokolo de la cela servo | Fiksita en la SSH-komando |
-D | SOCKS-intertraktado, poste aplikaja trafiko | Petita de la SOCKS-kliento |
Por unu retservilo, ĉi tio estas fiksa plusendo:
ssh -N -L 127.0.0.1:9080:web.example.com:80 [email protected]Vizitu http://127.0.0.1:9080/ kiel retejon. Ne etikedu pordon 9080 kiel SOCKS: ĝi plusendas bitokojn al la unu retservilo nomita en la komando. Malfermi retejon sub alia gastigantnomo ankaŭ povas influi ĝian virtualan gastigadon, alidirektilojn aŭ kuketojn.
Por SOCKS-auskultanto, la formo ŝanĝiĝas:
ssh -N -D 127.0.0.1:1080 [email protected]Agordi la aplikaĵon uzi SOCKS ĉe 127.0.0.1:1080. Enigi tiun adreson rekte en la adresbreton de la retumilo sendas retpeton al SOCKS-auskultanto, plia protokola miskongruo.
La manlibro de OpenSSH dokumentas ambaŭ formojn. Estas utila escepto: plusendi ekzistantan HTTP-prokurilon per -L produktas lokan pordon, kiu parolas la HTTP-prokuran protokolon, ĉar ĝia fiksa celo mem estas HTTP-prokurilo. La servo ĉe la malproksima fino decidas, kio apartenas al fiksa plusendo. Plusendi ekzistantan prokurilon per SSH konservas la protokolon kaj konton de tiu prokurilo.