DNAT en un contenedor VPN: reenvío, no INPUT

La petición llega dirigida a la IP del túnel y sale del mismo contenedor dirigida a un servicio vecino. Entre esos dos momentos, DNAT reescribió el destino y el paquete dejó de ser entrada para el contenedor VPN. Ahora es tráfico reenviado, juzgado por otra regla. Ese cambio explica por qué una regla de cortafuegos que parece correcta para la dirección del túnel no tiene efecto sobre la conexión traducida.

Siga el paquete tras la traducción

Tome un grupo de clientes 10.90.0.0/24 y una dirección de túnel 10.90.0.1. Dos contenedores están en un mismo puente: 192.0.2.2 ejecuta la VPN y 192.0.2.3 ejecuta la aplicación. Un cliente se conecta a 10.90.0.1:8080, y la regla DNAT del espacio de nombres del contenedor VPN lo reescribe a la dirección y el puerto reales de la aplicación. Luego una ruta envía el paquete por el puente. Esas direcciones son ilustrativas, no una receta de despliegue.

El puerto en el que la aplicación escucha realmente puede diferir de cualquier puerto publicado en el host. Lea el oyente dentro del contenedor en lugar de suponer que ambos números coinciden.

El permiso pertenece a la ruta de reenvío

El contenedor VPN necesita reenvío de IP y una decisión de reenvío acotada al grupo de clientes, la dirección de la aplicación y el puerto previsto. Las respuestas establecidas necesitan su propio permiso. Una regla que coincide con la dirección original del túnel no coincidirá tras el DNAT, porque el destino ya ha cambiado. Un permiso INPUT es el gancho equivocado para tráfico que ya no se dirige a este host.

Mantenga el alcance estrecho: un rango de origen, un destino, un servicio. Una regla de reenvío permisiva es más fácil de escribir y mucho más difícil de defender después.

docker exec vpn-container ip route get 192.0.2.3
docker exec vpn-container iptables -t nat -S
docker exec vpn-container iptables -S FORWARD

Las cadenas de Docker no son las cadenas de su contenedor

Las reglas dentro del espacio de nombres del contenedor no son las reglas del host de Docker. Cuando el tráfico cruza de la interfaz del túnel al puente, el cortafuegos del puente del host puede tomar otra decisión. Con el backend iptables de Docker, las cadenas de reenvío documentadas y los puntos de coincidencia posteriores al DNAT son donde aparece esa decisión.

La referencia de cortafuegos de Docker describe esas cadenas y la coincidencia posterior al DNAT. No arregle una aceptación ausente desactivando la gestión del cortafuegos de Docker o haciendo permisiva cada cadena, porque eso elimina el límite que intenta usar.

Haga de la ruta de retorno una elección deliberada

Si se conserva la dirección de origen, la aplicación ve 10.90.0.x y debe encaminar las respuestas de vuelta a través del contenedor VPN. De lo contrario, su puerta de enlace Docker habitual las enviará al host, que no posee el túnel. La alternativa es una traducción de origen estrechamente acotada en el contenedor VPN, que simplifica la respuesta pero oculta el cliente a la aplicación. Elija a propósito y anote cuál eligió.

Pruebe una conexión permitida nueva desde un cliente corriente y luego confirme que los puertos no relacionados siguen cerrados. Cuando un paquete desaparece, inspeccione el espacio de nombres de la VPN, el de la aplicación y el registro propio de la aplicación. Un ping a la puerta de enlace del puente no es una prueba de aceptación del servicio.

Mantenga las reglas en la configuración de inicio admitida del contenedor, porque las ediciones interactivas desaparecen cuando se recrea. La publicación de un puerto en el host es otra vía de exposición y no hace falta solo porque el servicio sea alcanzable a través del túnel.