Quin trànsit d’aplicacions transporta realment una redirecció SSH?

El terminal es connecta, apareix el prompt i tothom accepta que l’accés SSH funciona. Després, un client de base de dades de l’ordinador portàtil encara no pot arribar a l’amfitrió privat, i es culpa la sessió. El que es va construir era una shell, que és una de les quatre interfícies ben diferents que SSH pot oferir. Anomeneu primer la interfície i després comproveu que l’aplicació realment la utilitza. L’ordre importa, perquè cada interfície falla a la seva manera.

Anomeneu la interfície abans de comparar res

El manual del client OpenSSH distingeix quatre mecanismes que és fàcil confondre. Una shell o una ordre remota s’executa a l’amfitrió SSH. Una redirecció local obre un sòcol d’escolta al client i fa la connexió posterior des del costat remot. Una redirecció remota fa el contrari, escoltant al costat del servidor. La redirecció dinàmica exposa un punt final SOCKS per als programes que saben com fer-lo servir.

• Shell: el programa s’executa a la màquina remota, no hi ha res escoltant localment.
• Redirecció local: el vostre portàtil té un port, l’amfitrió remot fa la connexió sortint.
• Redirecció remota: el costat remot té un port, el trànsit torna cap a vosaltres.
• Dinàmica: un servidor intermediari SOCKS al client, usat només per aplicacions que el reconeixen.

Cap d’aquestes instal·la una ruta. Un programa que ignora la configuració del servidor intermediari, o que parla UDP, o que resol noms pel seu compte, no es veu afectat per una sessió SSH activa. Això no és un error d’SSH; és l’abast de la interfície que heu triat.

Les redireccions local, remota i dinàmica difereixen en qui escolta

La distinció que decideix la majoria de casos és qui posseeix el sòcol d’escolta. Amb una redirecció local, el client escolta i l’extrem remot marca el destí, i per això l’adreça de destí es resol des del punt de vista del servidor. Amb una redirecció remota, el servidor escolta i la connexió es porta de tornada al vostre costat, i així exposeu un servei local sense publicar-lo directament.

ssh -N -L 5432:db.internal.example:5432 [email protected]
ssh -N -D 1080 [email protected]
ss -ltnp | grep -E '5432|1080'

La primera ordre enllaça el port 5432 al portàtil i el redirigeix a la base de dades tal com es veu des del bastió. La segona crea un servidor intermediari SOCKS al port 1080. La tercera ordre confirma quins processos escolten realment, i és l’única prova que la redirecció existeix en lloc d’haver fallat en silenci per un conflicte de ports.

La redirecció dinàmica mereix un avís propi: només cobreix les aplicacions que respecten SOCKS. Un navegador s’hi pot dirigir, a una eina de línia d’ordres se li pot dir que l’utilitzi, i un controlador de base de dades amb la seva pròpia pila de connexió normalment no pot. Suposar que tots els programes de la màquina ja utilitzen el túnel és l’error més comú en tot aquest àmbit.

El mode de dispositiu de túnel és l’única excepció de xarxa real

OpenSSH també admet la redirecció de dispositiu de túnel -w, que passa una interfície punt a punt en lloc d’un oient TCP. És un túnel de xarxa autèntic, i es configura deliberadament, no és un efecte secundari d’obrir una shell.

sudo ssh -w 0:0 [email protected]
ip addr show tun0

Necessita els números d’interfície corresponents disponibles als dos extrems, la configuració correcta al servidor i prou privilegis al client per crear el dispositiu. També necessita un pla d’adreçament i encaminament, perquè una interfície nua no porta cap política sobre quins destins hauria d’utilitzar.

I fins i tot així, el túnel acaba a l’amfitrió remot. Qualsevol protecció que hagi ofert el transport SSH s’acaba allà, i la connexió posterior és un salt separat. Una passarel·la VPN té la mateixa forma de frontera, i per això la comparació hauria de ser sobre abast i acabament, no sobre quina eina és més forta. Anomenar aquesta frontera en veu alta també resol la discussió sobre si un túnel «xifra-ho tot», perquè és evident que no.

Comproveu que la vostra aplicació utilitza la interfície que heu construït

La verificació és per aplicació, no per sessió. Una redirecció que funciona demostra que el port està enllaçat i que l’extrem remot pot marcar; no demostra que el programa que us importa s’hi hagi connectat.

curl -sS --socks5-hostname 127.0.0.1:1080 -o /dev/null -w '%{http_code}\n' https://app.internal.example/health
psql "host=127.0.0.1 port=5432 dbname=app sslmode=require" -c 'select 1'

La primera ordre envia una petició a través del punt final SOCKS amb el nom d’amfitrió resolt remotament, i la segona exercita el port de base de dades redirigit amb TLS encara obligatori. Executeu les mateixes proves amb la redirecció aturada per confirmar que fallen, perquè una prova que passa de les dues maneres mai no utilitzava el túnel.

Després compareu amb una VPN encaminada només en les dimensions que importen: quins destins queden coberts, quins protocols funcionen, on acaba la protecció i qui ha d’aprovar l’accés. Una redirecció d’un sol servei pot ser la resposta més estreta i millor, mentre que una VPN és la forma correcta quan moltes aplicacions necessiten el mateix camí de xarxa. Cap de les dues no concedeix tot el que és abastable des del seu extrem remot.