Redirección de puertos: qué es y qué resuelve

Publicado el 2026-09-12 por frfrand

Qué hace realmente un reenvío de puertos, en qué se diferencia de un proxy inverso y de un túnel SSH, y cuándo cada uno es la herramienta correcta.

"Redirección de puertos" suena a una sola cosa y en realidad se usa para tres mecanismos distintos que conviene separar, porque se eligen en momentos diferentes.

En todos, la idea de fondo es la misma: algo llega a una puerta y se entrega en otra, que puede estar en otra máquina.

1. El reenvío del router (NAT)

Es el clásico de la red doméstica. Tu router tiene una IP pública; las máquinas de adentro tienen direcciones privadas que Internet no puede alcanzar.

Un reenvío le dice al router: "todo lo que llegue al puerto 8080 de mi IP pública, mandalo al puerto 80 de la máquina 192.168.1.50".

Funciona en la capa de red: el router reescribe la dirección de destino del paquete. No entiende nada de lo que viaja adentro.

Es lo que se usa para exponer una consola de juegos, una cámara o un servidor casero. Y es también la forma más fácil de dejar algo expuesto sin querer, porque el router no valida nada de lo que pasa.

2. El proxy inverso

Acá el intermediario sí entiende lo que transporta. nginx recibe una petición HTTPS en el 443 y decide, según el dominio y la ruta, a qué aplicación interna mandársela.

server { server_name api.miempresa.com; location / { proxy_pass http://127.0.0.1:3000; } }

La diferencia importante: como habla HTTP, puede repartir por dominio (varios sitios en un mismo servidor), terminar el TLS, cachear, comprimir, limitar peticiones y agregar cabeceras. Un reenvío de router no puede hacer nada de eso.

Si lo que movés es tráfico web, casi siempre querés un proxy inverso y no un reenvío a secas.

3. El túnel SSH

El más subestimado de los tres, y el que más problemas resuelve en el día a día.

ssh -L 5432:localhost:5432 prod

Eso hace que el puerto 5432 del servidor aparezca como si fuera local en tu máquina. Tu cliente de base de datos se conecta a localhost y el tráfico viaja cifrado por SSH.

La gran ventaja: la base de datos no necesita estar abierta a Internet. No hay puerto expuesto, no hay escáner automático que la encuentre, y el acceso está atado a tu clave SSH.

También existe al revés (-R), que publica un puerto de tu máquina en el servidor. Útil para mostrarle a alguien algo que corre en tu laptop.

Cuál usar

• ¿Tráfico web, con dominios y certificados? Proxy inverso.
• ¿Acceso puntual tuyo a un servicio interno (base de datos, panel, Redis)? Túnel SSH.
• ¿Un protocolo que no es HTTP y tiene que estar público de verdad? Ahí sí, reenvío, con firewall bien apretado.

La pregunta que ordena la decisión: ¿esto tiene que estar abierto al mundo, o solamente a vos? Si la respuesta es "a mí", no abras un puerto: hacé un túnel.

Cómo lo usamos nosotros

Entre los servidores de ArduMaker el tráfico interno no sale a Internet para volver a entrar: viaja por túneles entre VPS, con los puertos publicados sólo del lado que los necesita. Un servicio en un servidor puede consumir una base que vive en otro sin que esa base tenga jamás una dirección pública.

Es el mismo principio de todo el sistema: lo que no necesita estar abierto, no se abre.