Publicación de puertos de Docker y orígenes VPN: dos coincidencias que se pierden

La regla dice permitir la dirección del servidor VPN hacia el servicio publicado, y aun así la conexión se corta. Ese resultado es habitual y no es un fallo de Docker. Dos coincidencias separadas están mal: el origen que escribiste puede no ser el origen que recibe el host, y el puerto que escribiste puede no ser el puerto que ve el filtro. Corregir ambos exige mirar la ruta del paquete en lugar del diagrama del servicio.

El mito: permite el servidor VPN y ya está

Una VPN enrutada puede conservar la dirección del túnel del cliente hasta el host de Docker. Una puerta de enlace que hace traducción de origen puede sustituir esa dirección por la suya. Ambos diseños son legítimos y producen orígenes distintos para la misma acción del usuario.

Así que la frase IP del servidor VPN describe una suposición, no una observación. Hasta que sepas cuál de los dos diseños tienes delante, la regla es una conjetura.

Origen: grupo de clientes o puerta traducida

Comprueba cuatro cosas en orden. Primera, el grupo de direcciones de clientes, por ejemplo 10.90.0.0/24. Segunda, si la puerta traduce ese grupo antes de que llegue al host. Tercera, el origen que el host observa realmente para una conexión nueva. Cuarta, si la autenticación de la aplicación distingue usuarios individuales, porque una dirección traducida compartida no puede.

Si el grupo se conserva, una regla que solo coincide con la dirección pública de la puerta deja fuera a todos los clientes. Si la puerta traduce a propósito, permitir la dirección traducida admite a todos los usuarios que hay detrás, lo que puede ser aceptable para un servicio con su propio inicio de sesión e inaceptable para cualquier otra cosa.

Puerto: el DNAT cambia el número que coincides

En la publicación habitual con puente de Linux e iptables de Docker, una asignación del host de 8443 al puerto 443 del contenedor se traduce antes de que se ejecute el filtro de reenvío. El paquete llega al filtro con puerto de destino 443. Una regla que coincide con 8443 en ese punto nunca se activa, aunque 8443 es lo que escribió el cliente.

El puerto publicado sigue existiendo en el seguimiento de conexiones, por eso el destino original se puede hacer coincidir allí cuando de verdad lo necesitas.

Decide qué número expresa la intención. Coincide con el puerto del contenedor posterior al DNAT cuando la regla protege el servicio dentro del contenedor. Coincide con el destino original con la opción conntrack cuando la regla debe describir qué pidió el cliente, y acepta el coste extra de coincidencia y el cuidado con el orden de las reglas que eso conlleva.

Cadena: DOCKER-USER, no INPUT

La guía de iptables de Docker sitúa la política de reenvío de usuario en la cadena DOCKER-USER, que se evalúa antes de las reglas de reenvío del propio Docker. Una regla copiada de un servicio del host a la cadena INPUT filtra el tráfico dirigido al host, no el tráfico reenviado a un contenedor. Ese error produce una regla que parece correcta y no tiene efecto en la ruta del contenedor.

Mantén el rango de origen, el puerto de destino efectivo, el protocolo y la interfaz de entrada juntos en la misma regla. Una aceptación solo por origen para cada destino reenviado es más amplia que permitir un solo servicio publicado.

Verifica con conexiones nuevas

Prueba ambas direcciones con conexiones nuevas: un cliente VPN permitido y un origen que debe seguir denegado. El estado de conexión existente puede mantener viva una sesión después de cambiar la política, así que una conexión antigua no demuestra nada sobre la regla nueva. Después comprueba la ruta de respuesta, porque el contenedor todavía tiene que enrutar de vuelta al origen que ve.

La guía de iptables de Docker documenta el orden de las cadenas y el comportamiento de traducción de puertos detrás de estas comprobaciones. Léela antes de copiar una receta y confirma qué backend usa el Docker instalado, porque el backend nftables integra la política de forma distinta.