Conexiones privadas entre servidores, sin VPN ni puertos abiertos
Cómo se comunican en Opfield servicios, bases de datos y servidores en distintas nubes: conexiones salientes con mTLS, Secure Links a través de relays, bases privadas con un usuario por enlace y lo que Opfield deja en tus manos.
Por el equipo de Opfield5 min de lecturaActualizado
Un caso habitual: la API corre en un proveedor de nube, su base de datos en otro y el sitio público en un tercer servidor. Para conectarlos, los equipos suelen montar una VPN entre los servidores o abrir el puerto de la base y limitarlo a una lista de direcciones. Las dos opciones funcionan, y las dos añaden algo que mantener y algo que atacar.
Opfield lo hace de otra manera. Tus servidores solo abren conexiones salientes, y el tráfico privado entre ellos pasa por relays sobre conexiones autenticadas. A continuación, cómo funciona y dónde están sus límites.
Los servidores se conectan hacia fuera, nada los espera
Tus servidores no necesitan puertos de gestión abiertos. Cada servidor ejecuta pequeños daemons de Opfield que se conectan hacia fuera al relay de Opfield, normalmente en 9443/tcp. La conexión siempre va por TLS, y los daemons no exponen ninguna API de gestión a la red. Un servidor en cualquier nube, o detrás de un NAT, puede unirse siempre que llegue al relay.
Cada servidor demuestra quién es
Añadir un servidor lleva un comando de instalación. Incluye un token de registro de un solo uso y la huella del certificado de Opfield. En el primer arranque, el daemon comprueba ese certificado antes de enviar nada. Solo envía el token si la huella coincide, así que un registro DNS equivocado o un proxy en el camino no pueden capturarlo.
Después, Opfield emite para el servidor su propio certificado mTLS desde la autoridad de certificación interna de Opfield. El daemon borra el token de su configuración y se vuelve a conectar con el certificado. A partir de ahí, el certificado es la identidad del servidor, y Opfield lo comprueba en cada flujo. No hay ningún secreto compartido que se pueda filtrar, y eliminar un servidor revoca su certificado, de modo que el daemon antiguo no puede volver a conectarse como ese servidor.
El tráfico público llega a un servicio sin publicar un puerto
Una ruta en un servidor nginx público puede apuntar a un contenedor, un despliegue o un servicio de Compose en otro servidor. Opfield los une con un Secure Link: una conexión privada y autenticada a través del relay. El servicio no publica ningún puerto en el host, y la ruta lo sigue por su identidad, así que un reinicio o una nueva versión no obligan a cambiar la ruta. Los Secure Links están disponibles en todos los planes, también en Community.
Las bases de datos siguen siendo privadas
PostgreSQL, los almacenes clave-valor y ClickHouse gestionados son privados por defecto. Cuando enlazas una aplicación con una base de datos, Opfield añade una red privada al contenedor, le da las variables de conexión y envía el tráfico por un túnel autenticado a través del relay. La base no escucha en ningún puerto público.
Cada enlace recibe su propio usuario de base de datos: un rol de Postgres dedicado, un usuario ACL del almacén clave-valor o un usuario de ClickHouse. La aplicación nunca recibe las credenciales del propietario, y eliminar el enlace revoca ese usuario. Si una herramienta externa necesita acceso directo, publicar un puerto de la base es una decisión explícita. Requiere autenticación en la base, y Opfield no abre el firewall del host para ello. Las bases de datos gestionadas requieren Personal o superior.
El relay funciona como un servicio propio y de larga duración, separado de la aplicación Opfield. Las actualizaciones normales de Opfield no lo recrean, así que las sesiones de base de datos ya abiertas siguen funcionando mientras la aplicación se reinicia.
Más de un relay
El tráfico privado no tiene por qué depender de una sola máquina. Además del relay que viene con Opfield, puedes añadir relays en otros hosts y formar un Relay Pool. El dominio de fallo de cada relay es su host físico, por eso dos relays en el mismo host no cuentan como redundantes.
Las conexiones nuevas se reparten entre los relays listos. Cuando vacías un relay (drain), las conexiones nuevas van a los demás y los flujos abiertos continúan. Las actualizaciones de los relays van firmadas y se despliegan de un relay en un relay. Las aplicaciones ven un único enlace lógico y no necesitan saber qué relay lo lleva. Opfield sigue siendo el plano de control: tus datos pasan por los relays, no por la aplicación Opfield.
Lo que Opfield no hace
Esto no es una VPN ni pretende serlo. Opfield no abre firewalls, no ofrece atravesar NAT y no crea una red overlay. Los servidores siguen siendo independientes, sin relaciones de confianza entre ellos.
Algunas cosas quedan en tus manos:
- Cada servidor tiene que llegar a los relays que tiene asignados, en
9443/tcppor defecto. Un relay es el único punto que acepta conexiones entrantes de tus servidores. - Los servidores nginx públicos necesitan
80/tcpy443/tcpabiertos para el tráfico web. - Un Secure Link protege el transporte y la elección del destino. Quién puede llamar a tu aplicación lo sigue decidiendo la aplicación.
Más información
La documentación explica paso a paso el registro de nodos, el Relay Pool, los upstreams seguros y los enlaces con bases de datos, incluidas las reglas de firewall para cada tipo de servidor.