Compartir la red de un contenedor VPN: qué pasa con el DNS

Compartir el espacio de nombres de red de un contenedor VPN da a tu aplicación las interfaces y las rutas del túnel. No le da el resolutor del túnel, ni una copia fusionada de nada más en el host. Esa brecha produce un fallo muy concreto: los nombres públicos se resuelven, los internos no, y la aplicación que falla parece estar usando el servidor DNS equivocado, porque lo está. La reparación suele ser más pequeña de lo que sugiere el diagnóstico.

Paso 1: Prueba desde la aplicación, no desde el host

Ejecuta la consulta dentro del contenedor que tiene el problema, no en el host ni en un navegador. docker exec app-container getent hosts db.internal responde a la única pregunta que importa: qué devuelve el resolutor de este proceso.

Si el host resuelve el nombre y el contenedor no, has encontrado el fallo. Todo lo demás es elegir una forma admitida de arreglarlo.

Paso 2: Lee el modelo admitido del runtime

La documentación de redes de Docker registra restricciones en las opciones de DNS para contenedores que comparten el modo de red de otro contenedor. En Compose network_mode: service:vpn vincula la aplicación al espacio de nombres del contenedor VPN, y por servicio dns la configuración no se comporta como lo hace en un servicio normal. La resolución que obtienes es la que tiene el espacio de nombres compartido.

Las redes de puente definidas por el usuario también usan el DNS integrado de Docker de forma distinta a la del puente predeterminado. Por eso una dns cláusula copiada de un ejemplo de puente que funciona puede no hacer absolutamente nada en una pila compartida. Comprueba la disposición antes de copiar la cláusula.

Una dirección de bucle invertido siempre se refiere al contexto de red correspondiente. Dentro de un espacio de nombres compartido, 127.0.0.1 no es el resolutor del host.

Paso 3: Sigue la consulta hasta su destinatario

Lee la configuración del resolutor de la aplicación y, después, cualquier DNS cifrado específico de la aplicación que esta incorpore, porque una aplicación que ejecuta su propio resolutor ignora el archivo que has editado. Luego comprueba si el resolutor elegido es alcanzable bajo las rutas y la política de cortafuegos de la VPN. Una dirección de resolutor al otro lado del túnel es inútil si el espacio de nombres no tiene ruta hasta ella. Confirma el destinatario antes de editar cualquier archivo.

Una página de comprobación de IP del navegador no puede decirte adónde fueron las consultas de nombres. Te dice adónde fue una conexión HTTP.

Paso 4: Arregla las dos clases de fallo de forma distinta

Si fallan los nombres de servicio mientras los nombres públicos funcionan, el problema es el descubrimiento de servicios dentro de la red de contenedores, no la lista de resolutores públicos. Cambiar todas las direcciones DNS públicas no creará registros que el mecanismo de descubrimiento de la red nunca recibió la petición de crear.

Si fallan las dos clases, empieza por la accesibilidad al resolutor. Si solo falla una, empieza por el mecanismo de descubrimiento. Las dos tienen propietarios distintos, por eso una reparación nunca cubre las dos.

Paso 5: Vuelve a probar tras recrear

Cambia la configuración mediante el mecanismo admitido del runtime y después recrea los contenedores en lugar de editar archivos dentro de uno en ejecución. Prueba un nombre privado nuevo, un nombre público nuevo y la petición de la aplicación que sigue a la consulta. Una edición en /etc/resolv.conf dentro de un contenedor desaparece al recrearlo y te convencerá de que la reparación funcionó cuando no lo hizo.

Anota el propietario del resolutor y el espacio de nombres esperado junto a la definición de la red compartida. La siguiente persona necesitará ambos.