Menú
Artículo Cloud

Cómo redirigir puertos bloqueados usando SSH Local Forwarding (y por qué deberías sentirte culpable al usarlo en producción).

Jose Antonio Pino

• 3 min de lectura
Cómo redirigir puertos bloqueados usando SSH Local Forwarding (y por qué deberías sentirte culpable al usarlo en producción).

Introducción: La Noche que el Firewall Ganó (Al Menos Temporalmente)

Todos hemos estado ahí: es tarde, hay un despliegue urgente, y de repente, el firewall decide que tu puerto favorito es un riesgo para la seguridad nacional. En mi caso, era el 8443, ese puerto "alternativo" para HTTPS que parece una buena idea hasta que te topas con políticas corporativas escritas por alguien que claramente nunca tuvo que resolver un problema a las 3 de la mañana.

Necesitaba exponer un servicio YA, pero el 8443 estaba bloqueado, y el equipo de infraestructura (bien descansado, seguramente) no estaba disponible para aprobar un ticket. ¿Mis opciones? Improvisar o morir en el intento.

1. El Plan A: Cloudflare Túnel (o "Cuando los Certificados Autofirmados Te Traicionan")

Primero, intenté ser sofisticado: "¡Usaré un túnel de Cloudflare! Así evito el firewall y todo queda en HTTPS, bonito y seguro." Error catastrófico.

  • Cloudflare exige un certificado válido.
    • "¿Y si uso uno autofirmado?" → Nope. Cloudflare lo detecta como "sospechoso" y te bloquea.
    • "¿Y Let’s Encrypt?" → Olvídalo. Para obtener un certificado válido, necesitas que el dominio resuelva correctamente y, lo más importante, que el puerto 80 o 443 esté abierto para el desafío ACME. Pero, oh sorpresa: el firewall bloquea todo lo que no sea tráfico estándar.
  • Conclusión frustrante: Si no tienes un certificado preconfigurado y el firewall no colabora, Cloudflare no es tu salvación.

2. El Plan B: SSH Local Forwarding (o "El Arte de Engañar al Sistema con lo que Ya Tienes")

Cuando las soluciones elegantes fallan, toca recurrir a lo que siempre funciona: SSH.

Si ya tienes acceso SSH al servidor (afortunadamente, en mi caso sí, porque estaba configurándolo), puedes usar Local Port Forwarding para redirigir el puerto bloqueado a través de un túnel seguro.

El Comando Mágico (y Por Qué Funciona)

ssh -L 8443:localhost:8443 usuario@servidor -N
  • -L 8443:localhost:8443 → Redirige el 8443 local al 8443 del servidor remoto, como si estuviera abierto en tu máquina.
  • -N → "No ejecutes nada, solo mantén el túnel." (Porque no necesitamos una shell, solo el tráfico).

¿Por qué esto esquiva el firewall?

  • Todo el tráfico pasa por el puerto 22 (SSH), que casi siempre está abierto (porque, ¿quién bloquea SSH?… bueno, mejor no respondas).
  • El firewall solo ve una conexión SSH normal, no detecta que estás redirigiendo otro puerto.
  • Bonus: No necesitas abrir el 8443 en el servidor de forma pública.

3. Advertencias Serias (Porque Todo Poder Conlleva Responsabilidad)

Antes de que te emociones y empieces a tunelar todo como un hacker de película, considera lo siguiente:

  1. No es una solución permanente.
    • Esto es un parche de emergencia, no una arquitectura. Si necesitas el puerto abierto a largo plazo, habla con el equipo de infraestructura (preferiblemente en horario laboral).
  2. Depende de tu conexión SSH.
    • Si se cae el túnel, se cae el acceso. Usa tmux o screen para mantenerlo vivo, o configura un sistema de reintentos automático.
  3. Riesgos de seguridad.
    • Si abusas de esto, podrías:
      • Violar políticas de seguridad (y tener una "conversación interesante" con el CISO).
      • Crear dependencias ocultas que luego nadie documenta (y que explotan en producción un domingo a las 4 AM).
  4. El firewall no es el enemigo (bueno, a veces sí).
    • Los puertos bloqueados suelen tener una razón: evitar exposiciones innecesarias.
    • Si el 8443 estaba cerrado, quizás era por algo. Pero, claro, eso no ayuda cuando el deadline es "para ayer".

Conclusión: La Victoria Pírrica del Desarrollador Nocturno

Al final, logré acceder al servicio, el despliegue se completó, y el cliente nunca supo que su "solución estable" dependió de un túnel SSH creado en medio de la desesperación.

¿Fue lo correcto? Probablemente no.
¿Funcionó? Sí.
¿Lo haría de nuevo? … Depende de cuánto café tenga a mano.

Moraleja final:

  • Cuando el sistema te dice "no", SSH te dice "sí, pero con cuidado".
  • Usa esto como último recurso, no como estándar.
  • Y, sobre todo… documenta el parche, porque alguien más lo encontrará en seis meses y maldecirá tu nombre.

PD: Si tu jefe pregunta, "todo estaba así desde el principio" 😉.

Compartir