Un port reenviat per SSH no sempre és un proxy SOCKS
Distingiu un reenviament local SSH fix d'un oient SOCKS dinàmic abans de configurar una aplicació.
Creeu un túnel SSH, poseu 127.0.0.1 i el seu port a la configuració de proxy del navegador i no es carrega res. L'oient pot estar funcionant perfectament. Potser només espera el tipus de trànsit equivocat.
| Reenviament | Què envia l'aplicació local | Elecció de destinació |
|---|---|---|
-L | El protocol habitual del servei de destí | Fixat a l'ordre SSH |
-D | Una negociació SOCKS i després el trànsit de l'aplicació | Sol·licitat pel client SOCKS |
Per a un sol servidor web, això és un reenviament fix:
ssh -N -L 127.0.0.1:9080:web.example.com:80 [email protected]Visiteu http://127.0.0.1:9080/ com a lloc web. No etiqueteu el port 9080 com a SOCKS: reenvia bytes a l'únic servidor web esmentat a l'ordre. Obrir un lloc sota un altre nom d'amfitrió també pot afectar l'allotjament virtual, les redireccions o les galetes.
Per a un oient SOCKS, la forma canvia:
ssh -N -D 127.0.0.1:1080 [email protected]Configureu l'aplicació perquè faci servir SOCKS a 127.0.0.1:1080. Introduir aquesta adreça directament a la barra d'adreces del navegador envia una petició web a un oient SOCKS, una altra discrepància de protocol.
El manual d'OpenSSH documenta les dues formes. Hi ha una excepció útil: reenviar un proxy HTTP existent amb -L produeix un port local que parla el protocol de proxy HTTP, perquè la seva destinació fixa és ella mateixa un proxy HTTP. El servei de l'extrem llunyà determina què pertany a un reenviament fix. Reenviar un proxy existent per SSH conserva el protocol i el compte d'aquell proxy.