¿Qué tráfico de aplicaciones transporta realmente un reenvío SSH?

La terminal se conecta, aparece el indicador y todos coinciden en que el acceso SSH funciona. Luego un cliente de base de datos del portátil sigue sin poder alcanzar el host privado, y se culpa a la sesión. Lo que se construyó fue un shell, que es una de las cuatro interfaces bastante distintas que SSH puede ofrecer. Nombra primero la interfaz y luego comprueba que la aplicación realmente la usa. El orden importa, porque cada interfaz falla a su manera.

Nombra la interfaz antes de comparar nada

El manual del cliente OpenSSH distingue cuatro mecanismos que es fácil confundir. Un shell o un comando remoto se ejecuta en el host SSH. Un reenvío local abre un socket de escucha en el cliente y hace la conexión posterior desde el lado remoto. Un reenvío remoto hace lo contrario, escuchando en el lado del servidor. El reenvío dinámico expone un extremo SOCKS para programas que saben usarlo.

• Shell: el programa se ejecuta en la máquina remota, nada escucha localmente.
• Reenvío local: tu portátil tiene un puerto, el host remoto hace la conexión saliente.
• Reenvío remoto: el lado remoto tiene un puerto, el tráfico vuelve hacia ti.
• Dinámico: un proxy SOCKS en el cliente, usado solo por aplicaciones que lo entienden.

Ninguno de estos instala una ruta. Un programa que ignora la configuración del proxy, o habla UDP, o resuelve nombres por su cuenta, no se ve afectado por una sesión SSH activa. Eso no es un fallo de SSH; es el alcance de la interfaz que elegiste.

Los reenvíos local, remoto y dinámico difieren en quién escucha

La distinción que decide la mayoría de los casos es quién posee el socket de escucha. Con un reenvío local, el cliente escucha y el extremo lejano marca el destino, por eso la dirección de destino se resuelve desde el punto de vista del servidor. Con un reenvío remoto, el servidor escucha y la conexión se lleva de vuelta a tu lado, y así expones un servicio local sin publicarlo directamente.

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

El primer comando enlaza el puerto 5432 en el portátil y lo reenvía a la base de datos tal como se ve desde el bastión. El segundo crea un proxy SOCKS en el puerto 1080. El tercer comando confirma qué procesos escuchan realmente, y esa es la única prueba de que el reenvío existe en lugar de haber fallado en silencio por un conflicto de puertos.

El reenvío dinámico merece su propia advertencia: solo cubre aplicaciones que respetan SOCKS. Un navegador puede apuntarse a él, a una herramienta de línea de comandos se le puede indicar que lo use, y un controlador de base de datos con su propia pila de conexión normalmente no puede. Suponer que todos los programas de la máquina ya usan el túnel es el error más común en todo este terreno.

El modo de dispositivo de túnel es la única excepción de red real

OpenSSH también admite el reenvío de dispositivo de túnel -w, que pasa una interfaz punto a punto en lugar de un escucha TCP. Es un túnel de red auténtico, y se configura a propósito, no es un efecto secundario de abrir un shell.

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

Necesita los números de interfaz correspondientes disponibles en ambos extremos, la configuración correcta en el servidor y privilegios suficientes en el cliente para crear el dispositivo. También necesita un plan de direccionamiento y enrutamiento, porque una interfaz desnuda no lleva ninguna política sobre qué destinos deberían usarla.

Incluso entonces, el túnel termina en el host lejano. Cualquier protección que haya aportado el transporte SSH acaba allí, y la conexión posterior es un salto aparte. Una puerta de enlace VPN tiene la misma forma de frontera, por eso la comparación debería tratar del alcance y la terminación y no de qué herramienta es más fuerte. Nombrar esa frontera en voz alta también zanja la discusión sobre si un túnel «cifra todo», porque está claro que no.

Comprueba que tu aplicación usa la interfaz que construiste

La verificación es por aplicación, no por sesión. Un reenvío que funciona demuestra que el puerto está enlazado y que el extremo lejano puede marcar; no demuestra que el programa que te importa se haya conectado a través de él.

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'

El primer comando envía una petición a través del extremo SOCKS con el nombre de host resuelto de forma remota, y el segundo ejercita el puerto de base de datos reenviado con TLS todavía obligatorio. Ejecuta las mismas pruebas con el reenvío detenido para confirmar que fallan, porque una prueba que pasa de las dos maneras nunca usaba el túnel.

Luego compara con una VPN enrutada solo en las dimensiones que importan: qué destinos quedan cubiertos, qué protocolos funcionan, dónde acaba la protección y quién debe aprobar el acceso. Un reenvío de un solo servicio puede ser la respuesta más estrecha y mejor, mientras que una VPN es la forma correcta cuando muchas aplicaciones necesitan el mismo camino de red. Ninguna de las dos concede todo lo alcanzable desde su extremo remoto.