Puertos y rutas de red

El responsable de la plataforma define la ubicación y las direcciones de servicio, el responsable de la red aprueba las rutas y los responsables de los servicios deciden qué endpoints públicos necesitan sus aplicaciones. Los cortafuegos de los hosts siguen siendo responsabilidad tuya: Opfield no los abre ni ofrece atravesar NAT.

El objetivo predeterminado es sencillo: los usuarios llegan a Opfield y al Ingress público por HTTPS; los nodos gestionados inician conexiones salientes autenticadas hacia Relay; las bases de datos internas y las interfaces de control siguen siendo privadas. Añade exposición solo para una ruta del producto documentada.

Resumen de conectividad

Ruta	Finalidad
Cliente -> Opfield HTTPS	Consola, REST, OAuth, MCP, WebSockets, proxy de inferencia
Daemon gestionado -> Relay 9443/tcp	Control saliente autenticado y tráfico de túneles compatible
Internet -> nginx 80/tcp	HTTP y ACME HTTP-01 cuando se use
Internet -> nginx 443/tcp	Routes HTTPS públicas y Pages
Opfield/daemon -> proveedores externos	DNS, OIDC, correo, Git, registros, actualizaciones, ACME, proveedores de IA
Servicios internos de Opfield	PostgreSQL, Redis, gRPC interno, callbacks del inference core

El responsable público de 9443/tcp es Relay, no la aplicación Opfield. Los workers remotos de Relay deben anunciar endpoints de datos accesibles desde los hosts gestionados asignados.

Mantén privados PostgreSQL, Redis, el gRPC interno, el inference core, los puertos de propietario de las bases de datos, las interfaces de control de los daemons y las redes Docker específicas de cada vinculación.

Dirección de la conectividad

Los daemons gestionados inician conexiones salientes autenticadas hacia Relay. Normalmente, los operadores no exponen los puertos de control de los daemons a Opfield. Los workers remotos de Relay son la excepción: su endpoint anunciado 9443/tcp debe ser accesible desde los hosts gestionados que tengan asignados.

Los nodos de ingress reciben el tráfico público de las aplicaciones en los puertos 80 y 443 según los requisitos de las Routes y de ACME. Los nodos Docker y Storage no necesitan puertos públicos de cargas de trabajo ni de propietario para los Secure Links. Un endpoint publicado de una base de datos gestionada es una opción explícita y debe restringirse de forma independiente.

Planificación del cortafuegos

Origen	Destino	Necesario cuando
Usuario/navegador	Opfield HTTPS	Consola, REST, OAuth, MCP, WebSockets, inferencia
Nodo gestionado	Relay asignado 9443/tcp	Siempre, para el control gestionado y los túneles compatibles
Nodo Docker de una política de Availability en modo lease, y nodo Ingress de sus Routes	todos los Relays del pool, 9443/tcp por defecto	Conmutación por error del plano de datos: el tráfico de leases y los Secure Links de los miembros usan todos los Relays
Internet/cliente	Ingress 80/tcp	Route HTTP o ACME HTTP-01
Internet/cliente	Ingress 443/tcp	Routes HTTPS y Pages
Opfield/nodo	Endpoints de DNS y de actualizaciones	Resolución de nombres y descarga de actualizaciones firmadas
Opfield/Build Worker	Proveedores de Git y de registros	Descubrimiento de código, entrada de builds, push/pull
Opfield	Proveedores de OIDC, SMTP, DNS, webhooks, SIEM e IA	Solo para integraciones activadas
Cliente de la aplicación	puerto TLS publicado de la base de datos	Solo cuando el acceso directo se activa deliberadamente
Opfield	Servicio de licencias por HTTPS: license.opfield.dev, o la dirección indicada en LICENSE_SERVICE_URL	Registro y heartbeats; activación de claves de pago; actualizaciones de Opfield en una instalación que tiene o tuvo un plan de pago (las instalaciones Community sin clave también se actualizan mientras el servicio no está accesible).
Opfield	Servicio de actualizaciones get.opfield.dev por HTTPS	Comprobación de versiones y descargas firmadas
Opfield	Cuenta en la nube account.opfield.dev por HTTPS	Solo mientras Opfield Cloud está conectado; una conexión saliente
Cliente de almacenamiento	puerto S3 del almacenamiento gestionado (9000 por defecto)	Solo cuando la publicación se activa deliberadamente
Nodo Storage	ghcr.io y, como alternativa, Docker Hub	Descarga de las imágenes de bases de datos y almacenamiento gestionados; el runner de copias de seguridad solo procede de ghcr.io
Nodo Docker	ghcr.io y, como alternativa, Docker Hub	Descarga del runtime de Compose fijado
Nodo Storage que ejecuta las copias de seguridad	bases de datos externas, endpoints de almacenamiento y ghcr.io	Copias de seguridad y restauraciones de bases de datos
Destino de restauración clave-valor externo	IP del servicio ejecutor, TCP 20000–39999	Solo durante una restauración en un almacén clave-valor externo
Servidor ClickHouse externo	Endpoint S3 de preparación	Copias de seguridad y restauraciones de ClickHouse externo

Usa listas de permitidos del proveedor y políticas de salida cuando sea posible, pero incluye la validación de certificados, las redirecciones, el DNS y los endpoints de paquetes y registros que requiera la función seleccionada. No uses una regla amplia de «permitir todo» para ocultar una dependencia sin resolver.

Selección de direcciones

Opfield registra las direcciones locales y públicas informadas y las direcciones de servicio de cada rol. Elige las direcciones según la ruta real del par: clientes públicos hacia Ingress, hosts gestionados hacia Relay, operaciones Docker entre nodos hacia direcciones de servicio accesibles y certificados de bases de datos hacia las IP de servicio publicadas.

Cambiar una dirección puede requerir actualizar el DNS, rotar certificados, migrar Routes o reequilibrar Relay. Verifica cada par antes de eliminar la ruta antigua.

Verificación

Prueba desde la red de origen real, no solo desde el host de destino. Confirma el DNS, la accesibilidad TCP, la identidad TLS, el comportamiento del protocolo HTTP o gRPC y el estado que informa Opfield. Una conexión TCP correcta por sí sola no demuestra la autenticación ni que la aplicación esté lista.

Procedimiento de cambio y reversión

Antes de cambiar una dirección pública, un endpoint de Relay, una regla de cortafuegos, un registro DNS o la identidad de un certificado, enumera todos los pares que usan esa ruta y define un periodo en el que convivan la ruta antigua y la nueva. Reduce el TTL del DNS solo cuando el DNS forme parte del cambio, y hazlo con la antelación suficiente para que surta efecto. Mantén disponible la ruta antigua hasta que la verificación externa y la reconexión de los nodos gestionados demuestren que la nueva funciona.

Revierte restaurando la dirección, el valor DNS, el certificado o la asignación anteriores como un único cambio coordinado. Evita alternar entre configuraciones mientras las cachés y las conexiones de larga duración siguen activas. Tras la reversión, verifica las sesiones de Relay, la actualidad de los datos de los nodos, las Routes, Pages, las vinculaciones de bases de datos, los webhooks y la salida hacia los proveedores y fuentes de código que use la instalación.

Diagnóstico para operadores

Haz una comprobación por capas desde el origen real:

1. El DNS devuelve la dirección prevista.
2. La ruta de red y el cortafuegos permiten el puerto de destino documentado.
3. TLS presenta la identidad esperada y una cadena de confianza.
4. El protocolo de la aplicación completa la autenticación o las comprobaciones de estado.
5. Opfield recibe un estado nuevo informado por el propietario.

Registra qué capa falla. Abrir más puertos no corrige un problema de certificado, autorización, política o preparación de la aplicación.