Cuándo conviene una redirección de puertos y cuándo no

Publicado el 2026-09-12 por frfrand

Una guía corta para decidir entre abrir un puerto, poner un proxy inverso o levantar un túnel, y la pregunta que resuelve el noventa por ciento de los casos.

Casi siempre que alguien pregunta "¿cómo abro este puerto?", la respuesta correcta es "probablemente no lo abras".

No por paranoia. Porque abrir un puerto es una decisión que cuesta poco hoy y mucho durante los próximos años, y hay alternativas que resuelven lo mismo sin esa cuenta pendiente.

La pregunta que ordena todo

Antes de tocar el firewall, respondé una sola cosa:

¿Esto tiene que estar disponible para el mundo, o solamente para vos y tu equipo?

Si la respuesta es "para el mundo", necesitás exponerlo, y conviene hacerlo bien. Si la respuesta es "para nosotros", no abras nada: usá un túnel.

Suena simple porque lo es. El problema es que la primera vez que necesitás conectarte a la base desde tu casa, abrir el puerto parece lo más rápido. Y después queda abierto.

Lo que pasa cuando abrís un puerto

No es una metáfora: poné un servicio nuevo en una IP pública y mirá los logs a las dos horas.

Hay redes enteras dedicadas a escanear todo el espacio de direcciones de Internet, todo el tiempo. No te eligieron a vos: barren todo. Un puerto abierto aparece en sus listas en minutos.

Eso no significa que te van a entrar. Significa que a partir de ese momento la seguridad de ese servicio depende enteramente de lo bien configurado que esté, de su versión, y de que apliques los parches. Para siempre.

Para un servidor web eso es aceptable: es su trabajo. Para una base de datos o un panel de administración, casi nunca vale la pena.

Los tres casos donde sí

Un servicio público de verdad. Una web, una API que consumen terceros, un servidor de correo. Es su razón de existir.

Un protocolo que no es HTTP y necesita acceso directo. Juegos, algunos sistemas de mensajería, dispositivos que no saben hacer otra cosa.

Un webhook entrante. Un servicio externo necesita golpear tu puerta. Acá vale la pena aclarar algo: un webhook entra por HTTPS, así que no hace falta abrir un puerto nuevo. Entra por el 443 que ya tenés, y lo enruta tu proxy inverso.

Y los casos donde casi nunca

Bases de datos. PostgreSQL, MySQL, Redis, Mongo. Si tu aplicación vive en el mismo servidor, la base no necesita salir a la red en absoluto. Si vive en otro servidor, usá una red interna o un túnel entre los dos.

Paneles de administración. phpMyAdmin, Adminer, el panel de tu framework. Son objetivos clásicos justamente porque mucha gente los deja abiertos.

Cualquier cosa "temporal". No existe el puerto temporal. Existe el puerto que abriste y no cerraste.

La alternativa concreta

ssh -L 5432:localhost:5432 prod

Con eso, el puerto 5432 del servidor aparece en tu máquina como si fuera local. Tu cliente se conecta a localhost, el tráfico va cifrado por SSH, y el servidor no tiene ningún puerto de base de datos expuesto.

Si la conexión se corta cuando cambiás de red, autossh la reconecta sola.

Y para un equipo entero, la versión escalada de la misma idea es una VPN o una red tipo Tailscale: las máquinas se ven entre sí como si estuvieran en la misma oficina, sin que ninguna tenga un puerto abierto al mundo.

Si igual tenés que abrir

Tres mínimos que cambian mucho el riesgo:

• Limitá por origen. Si sólo entra tu oficina, permití sólo esa dirección. La mayoría de los firewalls lo permite en una línea.
• Poné algo adelante. Un proxy inverso con límite de peticiones absorbe la mayor parte del ruido.
• Anotá por qué lo abriste y cuándo revisarlo. Los puertos abiertos sin dueño son los que sobreviven años.

En ArduMaker todo empieza cerrado y se abre declarándolo, justamente para que abrir sea una decisión y no un descuido. Y para lo interno hay túneles entre VPS, así el tráfico entre tus propios servidores nunca sale a Internet para volver a entrar.