Redirecció dinàmica d’SSH com a proxy SOCKS sobre la vostra VPN

Una aplicació que només parla SOCKS no té amb què parlar en una VPN corrent, perquè el túnel transporta paquets i l’aplicació vol un punt de proxy. OpenSSH pot proporcionar aquest punt quan el propietari de l’accés ho permet, ja que la redirecció dinàmica converteix una sessió SSH en un proxy local. Després hi ha dos salts que cal mantenir separats: el túnel que arriba a l’amfitrió SSH i la connexió que aquest amfitrió obre després. Separar-los explica tant per què funciona aquesta disposició com què no farà mai.

Què arriba a ser l’oient SSH i què no

La redirecció dinàmica fa que el client SSH escolti localment i parli SOCKS4 o SOCKS5 amb tot el que es connecti. Cada petició anomena una destinació i el servidor SSH obre la connexió següent, i per això la consulta de la destinació pot passar a l’extrem remot. Això és redirecció TCP a nivell d’aplicació, no una VPN per a tot el dispositiu. No transporta cap associació UDP, ni ICMP, ni res per a aplicacions que ignoren del tot la configuració de proxy. El salt del servidor SSH a l’aplicació tampoc no és dins del vostre túnel, cosa que importa quan la destinació només accepta trànsit de xarxes conegudes.

Els requisits previs són reals: una ruta fins a l’amfitrió SSH, un compte autoritzat, una clau d’amfitrió del servidor verificada i permís per redirigir. Cap d’ells no el crea el proxy, i l’últim sol ser el primer que falta. Confirmeu tots quatre abans de depurar qualsevol altra cosa, perquè la fallada es veu igual des del client sigui quin sigui el que falta.

Inicieu-lo al loopback amb un port explícit

Trieu un port local no utilitzat i lligueu-lo explícitament al loopback en lloc de deixar l’adreça sense especificar. Les tres opcions de sota existeixen cadascuna per un motiu.

ssh -D 127.0.0.1:1080 -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
  [email protected]

-N omet l’ordre remota i -T omet el pseudo-terminal, així que la sessió només existeix per redirigir. ExitOnForwardFailure fa que el client surti quan no es pot crear l’oient, en lloc d’executar-se sense la redirecció que heu demanat. ControlPath=none manté la sessió fora d’una connexió multiplexada existent que podria afegir les seves pròpies redireccions. El loopback manté l’oient fora de la LAN, però en una màquina compartida no és cap frontera d’autorització, perquè altres processos locals també hi poden arribar. La referència del client OpenSSH documenta totes aquestes opcions, i l’avís del loopback es desprèn de què és un sòcol que escolta.

Envieu els noms a través del proxy, no al seu voltant

Un client SOCKS5 pot resoldre la destinació ell mateix o demanar-ho al proxy, i aquesta tria decideix quin resolutor respon. Amb socks5h, curl envia el nom d’amfitrió a través del proxy, així que la consulta es fa al servidor SSH. Amb socks5 simple, l’ordinador portàtil resol primer i només viatja la connexió, cosa que anul·la silenciosament l’objectiu quan el nom és intern. La petició de sota també buida la llista de sense-proxy, així que un valor NO_PROXY heretat no pot encaminar-la al voltant del proxy.

curl -sS --noproxy '' --proxy socks5h://127.0.0.1:1080 https://app.corp.example/health

La validació del certificat i l’inici de sessió propi de l’aplicació continuen aplicant-se, perquè el proxy no substitueix cap dels dos. Queden dues consultes: l’ordinador portàtil ha d’arribar a l’amfitrió SSH pel camí permès de VPN i DNS, i el servidor SSH ha de resoldre ell mateix el nom de l’aplicació. La segona es pot provar per separat abans que cap trànsit passi pel proxy.

ssh [email protected] getent hosts app.corp.example

Demostreu una destinació permesa i després tanqueu la sessió

Proveu una destinació que la política permet i una que hauria de refusar, perquè una redirecció que funciona només demostra que l’oient funciona i res més. L’aplicació veu l’adreça d’origen que tria el servidor SSH, que no és l’adreça del túnel del vostre ordinador portàtil. On l’extrem remot registra les connexions per origen, aquesta diferència és el primer que cal mirar quan es rebutja una petició.

Atureu la sessió a través del procés que la posseeix en lloc de matar un shell no relacionat. Després confirmeu que l’oient ha desaparegut, perquè un port que encara respon és una sessió que no heu tancat de veritat. Traieu només la configuració de proxy que ha introduït aquest exercici i deixeu la resta de la configuració de l’aplicació tranquil·la. Un terminal desatès amb una regla de redirecció no és cap servei, i un proxy permanent necessita un cicle de vida aprovat, no una finestra oblidada.

ss -ltn | grep 1080

Fallades que aquesta disposició no pot arreglar

Alguns símptomes apunten directament als límits de dalt, i reconèixer-los aviat estalvia una tarda de depuració del proxy. La taula relaciona el que veieu amb el que normalment significa. Qualsevol cosa de l’última columna és una qüestió de disseny, no un error de configuració.

Les tres primeres files són les que la gent diagnostica malament, perquè cadascuna produeix un intent de connexió en lloc d’un error sobre el proxy mateix. Un nom que es resol a l’ordinador portàtil no diu res sobre el resolutor del servidor, i la fallada es llegeix en canvi com un problema de certificat o de temps d’espera. Les aplicacions només UDP queden fora del disseny, no trencades dins seu, i cap opció ssh addicional ho canvia. La fila del navegador és el recordatori habitual que la configuració de proxy és per aplicació. L’última fila és la raó per la qual existeix la comprovació de tancament: un port que encara escolta vol dir que ara el posseeix una altra cosa.