Tuneles SSH

Introducción

Los túneles SSH permiten mover tráfico a través de un canal encriptado para acceder a servicios detrás de firewalls, subredes privadas o NAT, reutilizando conexiones SSH existentes. Esta guía cubre los cuatro tipos principales:

• reenvío de puerto local

• reenvío de puerto remoto

• renvío a través de un bastión

• reenvío dinámico (SOCKS5)

Reenvío de Puerto Local

El reenvío de puerto local abre un puerto en tu máquina local que redirige tráfico encriptado a un servicio remoto, ideal para servidores con SSH accesible pero otros puertos bloqueados (ej. HTTP en puerto 80).

Configuración del Laboratorio

• Cliente: 192.168.60.10 (ejecuta comandos SSH).

• Servidor Web: 192.168.60.11 (sitio web en puerto 80, SSH habilitado).

Verifica acceso directo inicial: curl http://webserver.

Simulación de Bloqueo de Firewall

En el servidor web:

sudo ufw allow ssh
sudo ufw enable
sudo ufw status

Ahora curl http://webserver falla (timeout). Usa --max-time 5 para evitar esperas indefinidas.

Creación del Túnel

Sintaxis: ssh -L [local_host:]local_port:remote_host:remote_port user@ssh_server.

Ejemplo: ssh -N -L localhost:8080:localhost:80 vagrant@webserver.

• -L: Reenvío local.

• -N: Sin comandos remotos (solo túnel).

• localhost:8080: Puerto local.

• localhost:80: Destino desde perspectiva del servidor SSH.

El túnel "cuelga" esperando tráfico. Verifica: lsof -i :8080 y sudo ss -tnp | grep sshd.

Prueba: curl localhost:8080 accede al sitio vía túnel, saltando el firewall.

Aclarando "localhost"

• Primer localhost:8080: Tu máquina local (loopback por defecto; usa -g para interfaces externas, ej. ssh -N -g -L 192.168.60.10:8080:localhost:80 vagrant@webserver).

• Segundo localhost:80: Desde el servidor SSH (cámbialo por IP/host interno si es otro máquina).

Usa -f para fondo: ssh -f -N -L ...; mata con kill <PID> vía lsof.

Diagrama de Flujo: Tráfico: Local 8080 → Túnel SSH → Remoto 80.

---

Reenvío de Puerto Remoto

Invierte la dirección: abre puerto en el remoto que redirige a tu local, útil para exponer servicios locales (ej. web dev) detrás de NAT/firewall vía un servidor público.

Configuración del Laboratorio

• james-lap (192.168.70.10): Web local en puerto 80.

• aws-pub-instance (192.168.70.10/192.168.80.20): Servidor público accesible.

• kay-pc (192.168.80.10): Accede al web de James.

Pings confirman: james/kay alcanzan aws-pub-instance, no entre sí. curl localhost en james-lap verifica web.

Creación del Túnel Remoto

Sintaxis: ssh -R remote_addr:remote_port:local_addr:local_port user@ssh_public.

Ejemplo completado: ssh -N -R localhost:8080:localhost:80 vagrant@aws-pub-instance (desde james-lap).

• -R: Reenvío remoto.

• localhost:8080: Puerto en aws-pub-instance.

• localhost:80: Servicio local en james-lap.

Verifica en aws-pub-instance: lsof -i :8080. Desde kay-pc: curl aws-pub-instance:8080 accede al web de James vía túnel.

Caso Práctico Completado: James muestra su app sin deploy público; Kay ve como si estuviera en la nube. Para acceso externo, usa IP pública del bastión con -g.

---

Túneles a Través de Bastión (Proxy)

Usa un bastión (máquina intermedia pública) para alcanzar internos via reenvío local extendido.

Configuración

• Cliente (externo).

• Bastión (público, accede a red interna).

• Interno (oculto, ej. DB en 10.0.0.5:5432).

Sintaxis: ssh -L local_port:interno_host:interno_port user@bastion.

Ejemplo completado: ssh -N -L 5432:10.0.0.5:5432 user@bastion-ip.

• Tráfico: Local 5432 → Bastión → Interno 5432.

Diagrama: Cliente → Bastión (SSH) → Interno (local desde bastión).

ProxyJump Simplificado: ssh -J user@bastion user@interno o en ~/.ssh/config:

textHost bastion
  HostName bastion-ip
Host interno
  HostName 10.0.0.5
  ProxyJump bastion

Útil para clústeres AWS/GCP sin exponer puertos.

---

🚧 Reenvío Dinámico (SOCKS5)

SSH como proxy SOCKS5 local para cualquier TCP destino dinámico, como VPN ligera. Ideal para browsing geo-restringido o encriptación.

Configuración del Lab

• Cliente (192.168.60.10), Webserver (192.168.60.11, SSH).

• Limpia: En webserver, sudo ufw disable.

Simulación de Restricción de Red

Bloquea HTTP/HTTPS saliente en cliente (simula ISP):

textsudo ufw default deny outgoing
sudo ufw allow out ssh
sudo ufw enable

Prueba falla: curl --max-time 5 google.com (timeout).

Creación del Túnel Dinámico

Sintaxis: ssh -D [bind_address:]local_port user@ssh_server. Ejemplo completado: ssh -N -D 1080 vagrant@webserver.

• -D: Proxy SOCKS5 en puerto 1080 (loopback por defecto).

• SSH "cuelga" escuchando.

Verifica: lsof -i :1080 (SSH en LISTEN).

Verificación del Proxy

Configura app/herramienta para SOCKS5 localhost:1080.

• curl: curl --socks5 localhost:1080 google.com (éxito vía webserver).

• Navegador: Firefox/Chrome → Configuración → Proxy manual SOCKS5 (127.0.0.1:1080). Visita google.com (IP origen: webserver).

• ss: sudo ss -tnp | grep ssh confirma conexión.

Diagrama de Flujo Completado: App → SOCKS5 local 1080 → Túnel SSH → Webserver → Destino TCP (DNS resolvido remotamente).

Desactiva: Ctrl+C o kill <PID>.

Casos Prácticos Completados:

• Geo-bypass: Túnel a servidor en país deseado.

• Pip/APT: pip --proxy socks5://localhost:1080 install pkg.

• Global: -g -D 0.0.0.0:1080 (cuidado, expone proxy).​

Consejos Avanzados

Opción	Uso	Ejemplo
-f -N	Fondo, sin shell	ssh -f -N -D 1080 user@host
autossh	Reconexión	autossh -M 0 -D 1080 user@host
Config SSH	Persistente	DynamicForward 1080 en ~/.ssh/config
Seguridad	Claves, intervalos	ServerAliveInterval 60, keys con ssh-add

Integra con tmux para persistencia. Evita exposición innecesaria (-g).

Referencias

• Se basa en artículos de TRÄW (substack.com/@thatstraw, diciembre 2025), traducidos y completados para una visión integral.[es.smartling]​