Cómo movemos tráfico entre nuestros servidores sin exponerlo a Internet

Publicado el 2026-09-12 por frfrand

Cuando una app en un servidor necesita una base que vive en otro, hay dos caminos: abrir un puerto al mundo o hacer que se vean entre ellos. Por qué elegimos el segundo.

Es una de las situaciones más comunes en cuanto un proyecto crece un poco: la aplicación corre en un servidor y la base de datos en otro. ¿Cómo se hablan?

La respuesta rápida es abrir el puerto de la base y apuntar la app a la IP pública del otro servidor. Funciona en cinco minutos. Y deja una base de datos expuesta a Internet, que es exactamente lo que uno pasa los años siguientes tratando de evitar.

Nosotros lo resolvemos al revés.

El problema con la solución fácil

Abrir el 5432 al mundo tiene tres costos que no se ven el primer día:

• La base queda en las listas de los escáneres automáticos a los pocos minutos.
• La seguridad pasa a depender de la contraseña de la base y de que su versión no tenga vulnerabilidades. Para siempre.
• El tráfico entre tus dos servidores sale a Internet y vuelve a entrar, sumando latencia y un tramo que no controlás.

Ese último punto se subestima. Dos servidores del mismo proveedor, a veces en el mismo centro de datos, mandando consultas por la Internet pública.

Lo que hacemos en su lugar

Entre los VPS de ArduMaker el tráfico interno viaja por túneles cifrados entre las máquinas. Desde el punto de vista de la aplicación, la base está en localhost, en el puerto de siempre. Desde el punto de vista de Internet, el servidor de la base no tiene ningún puerto de base de datos abierto.

La pieza importante es la dirección en que se levanta el túnel: lo inicia el lado que necesita conectarse. Eso significa que el servidor que guarda los datos no necesita aceptar conexiones entrantes de nadie. No hay una puerta que proteger, porque no hay puerta.

Cómo se ve en la práctica

La configuración se hace desde el panel: se elige el VPS iniciador, el VPS receptor y qué puerto se publica de un lado al otro. A partir de ahí:

# en el servidor de la app, la base es local DATABASE_URL=postgres://usuario:clave@localhost:5432/midb

La cadena de conexión de tu aplicación apunta a localhost. Si mañana la base se muda a otro servidor, cambia la configuración del túnel y la aplicación ni se entera.

Ese desacople es la mitad del valor. La otra mitad es que la superficie expuesta no crece cuando crece tu infraestructura.

Qué se gana además

Menos configuración duplicada. No hay que mantener reglas de firewall por cada par de servidores que se hablan.

Reversible. Dar de baja un túnel no deja un puerto abierto olvidado: al cortar el túnel, el acceso desaparece.

Auditable. El túnel es un objeto de la plataforma, con su estado y su historial. Se puede contestar "¿quién puede hablar con esta base?" mirando una lista, y no reconstruyéndolo de reglas de iptables.

Claves propias. El receptor acepta sólo las claves que declaraste. Sumar un servidor nuevo es agregar su clave, y quitarlo es borrarla.

Cuándo no alcanza

Si lo que necesitás es que un servicio de terceros llegue a tu base (una herramienta de análisis alojada afuera, por ejemplo), un túnel entre tus servidores no resuelve eso. Ahí las opciones son una VPN que incluya a ese tercero, una réplica de sólo lectura pensada para exponerse, o una API propia que devuelva únicamente lo que ese tercero necesita.

La tercera suele ser la mejor, aunque dé más trabajo: es la única en la que vos decidís exactamente qué sale.

La idea de fondo

Es la misma que recorre toda la plataforma: lo que no necesita estar abierto, no se abre. Y cuando dos cosas tienen que hablarse, es mejor hacer que se vean entre ellas que hacerlas visibles para todos.