Que tráfico de aplicacións transporta realmente un reenvío SSH?

O terminal conéctase, aparece o indicador e todos coinciden en que o acceso SSH funciona. Despois un cliente de base de datos no portátil segue sen poder alcanzar o host privado, e cúlpase a sesión. O que se construíu foi unha shell, e é unha das catro interfaces bastante distintas que SSH pode ofrecer. Nomea primeiro a interface e logo comproba que a aplicación realmente a usa. A orde importa, porque cada interface falla á súa maneira.

Nomea a interface antes de comparar nada

O manual do cliente OpenSSH distingue catro mecanismos que é fácil confundir. Unha shell ou un comando remoto execútase no host SSH. Un reenvío local abre un socket de escoita no cliente e fai a conexión posterior desde o lado remoto. Un reenvío remoto fai o contrario, escoitando no lado do servidor. O reenvío dinámico expón un extremo SOCKS para programas que saben usalo.

• Shell: o programa execútase na máquina remota, nada escoita localmente.
• Reenvío local: o teu portátil ten un porto, o host remoto fai a conexión saínte.
• Reenvío remoto: o lado remoto ten un porto, o tráfico volve cara a ti.
• Dinámico: un proxy SOCKS no cliente, usado só por aplicacións que o entenden.

Ningún destes instala unha ruta. Un programa que ignora a configuración do proxy, ou fala UDP, ou resolve nomes pola súa conta, non se ve afectado por unha sesión SSH activa. Iso non é un fallo de SSH; é o alcance da interface que escolliches.

Os reenvíos local, remoto e dinámico difiren en quen escoita

A distinción que decide a maioría dos casos é quen posúe o socket de escoita. Cun reenvío local, o cliente escoita e o extremo afastado marca o destino, por iso o enderezo de destino resólvese desde o punto de vista do servidor. Cun reenvío remoto, o servidor escoita e a conexión lévase de volta ao teu lado, e así expós un servizo local sen publicalo directamente.

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

O primeiro comando enlaza o porto 5432 no portátil e reenvíao á base de datos tal como se ve desde o bastión. O segundo crea un proxy SOCKS no porto 1080. O terceiro comando confirma que procesos escoitan realmente, e esa é a única proba de que o reenvío existe en lugar de ter fallado en silencio por un conflito de portos.

O reenvío dinámico merece o seu propio aviso: só cobre aplicacións que respectan SOCKS. Un navegador pode apuntarse a el, a unha ferramenta de liña de ordes pódeselle dicir que o use, e un controlador de base de datos coa súa propia pila de conexión normalmente non pode. Supoñer que todos os programas da máquina xa usan o túnel é o erro máis común en todo este terreo.

O modo de dispositivo de túnel é a única excepción de rede real

OpenSSH tamén admite o reenvío de dispositivo de túnel -w, que pasa unha interface punto a punto en lugar dun escoitador TCP. É un túnel de rede auténtico, e configúrase a propósito, non é un efecto secundario de abrir unha shell.

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

Necesita os números de interface correspondentes dispoñibles nos dous extremos, a configuración correcta no servidor e privilexios suficientes no cliente para crear o dispositivo. Tamén necesita un plan de direccionamento e encamiñamento, porque unha interface espida non leva ningunha política sobre que destinos deberían usala.

Incluso entón, o túnel remata no host afastado. Calquera protección que aportase o transporte SSH acaba alí, e a conexión posterior é un salto aparte. Unha pasarela VPN ten a mesma forma de fronteira, por iso a comparación debería tratar do alcance e da terminación e non de que ferramenta é máis forte. Nomear esa fronteira en voz alta tamén resolve a discusión sobre se un túnel «cifra todo», porque está claro que non.

Comproba que a túa aplicación usa a interface que construíches

A verificación é por aplicación, non por sesión. Un reenvío que funciona demostra que o porto está enlazado e que o extremo afastado pode marcar; non demostra que o programa que che importa se conectase a través del.

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'

O primeiro comando envía unha petición a través do extremo SOCKS co nome de host resolto de forma remota, e o segundo exercita o porto de base de datos reenviado con TLS aínda obrigatorio. Executa as mesmas probas co reenvío detido para confirmar que fallan, porque unha proba que pasa das dúas maneiras nunca usaba o túnel.

Logo compara cunha VPN encamiñada só nas dimensións que importan: que destinos quedan cubertos, que protocolos funcionan, onde acaba a protección e quen debe aprobar o acceso. Un reenvío dun só servizo pode ser a resposta máis estreita e mellor, mentres que unha VPN é a forma correcta cando moitas aplicacións necesitan o mesmo camiño de rede. Ningunha das dúas concede todo o alcanzable desde o seu extremo remoto.