Un port redirecționat prin SSH nu este întotdeauna un proxy SOCKS
Distingeți o redirecționare locală SSH fixă de un ascultător SOCKS dinamic înainte de a configura o aplicație.
Creați un tunel SSH, introduceți 127.0.0.1 și portul său în setările de proxy ale browserului și nimic nu se încarcă. Ascultătorul poate funcționa perfect. S-ar putea să aștepte doar tipul greșit de trafic.
| Redirecționare | Ce trimite aplicația locală | Alegerea destinației |
|---|---|---|
-L | Protocolul obișnuit al serviciului țintă | Fixat în comanda SSH |
-D | O negociere SOCKS, apoi traficul aplicației | Solicitat de clientul SOCKS |
Pentru un singur server web, aceasta este o redirecționare fixă:
ssh -N -L 127.0.0.1:9080:web.example.com:80 [email protected]Accesați http://127.0.0.1:9080/ ca site web. Nu etichetați portul 9080 drept SOCKS: redirecționează octeți către singurul server web numit în comandă. Deschiderea unui site sub alt nume de gazdă poate afecta și găzduirea virtuală, redirecționările sau cookie-urile acestuia.
Pentru un ascultător SOCKS, forma se schimbă:
ssh -N -D 127.0.0.1:1080 [email protected]Configurați aplicația să folosească SOCKS la 127.0.0.1:1080. Introducerea acelei adrese direct în bara de adrese a browserului trimite o cerere web către un ascultător SOCKS, o altă nepotrivire de protocol.
Manualul OpenSSH documentează ambele forme. Există o excepție utilă: redirecționarea unui proxy HTTP existent cu -L produce un port local care vorbește protocolul de proxy HTTP, deoarece destinația sa fixă este ea însăși un proxy HTTP. Serviciul de la capătul îndepărtat determină ce aparține unei redirecționări fixe. Redirecționarea unui proxy existent prin SSH păstrează protocolul și contul acelui proxy.