Por que os contedores de Docker ignoran o resolución DNS da VPN

A VPN está activa, o navegador chega aos sitios internos e o contedor segue sen poder resolver os mesmos nomes. Unha instalación de paquete morre cun erro de resolución de nomes como EAI_AGAIN, ou unha aplicación non atopa un host de base de datos que a máquina anfitrioa resolve sen queixa algunha. O contedor non usa o resolutor que instalou a VPN. Docker copiou a configuración do resolutor do anfitrión cando se creou o contedor, e nada a volveu copiar despois.

Dúas vistas do resolutor nunha mesma máquina

En Linux, Docker dá a cada contedor unha copia de a configuración do resolutor do anfitrión no momento de crealo, filtra as direccións de loopback e executa un servidor DNS integrado en 127.0.0.11 que reenvía as consultas cara a fóra. Un cliente de VPN que reescriba /etc/resolv.conf despois de que o contedor arrancase non cambia nada dentro del. Reiniciar o contedor só axuda se o resolutor do anfitrión resulta correcto nese momento.

Docker Desktop en macOS ou Windows engade unha capa, porque o demo vive nunha máquina virtual. Pode que o resolutor da VPN do anfitrión nunca sexa visible para esa VM, así que reiniciar non cambia absolutamente nada. Compara as dúas vistas antes de escoller unha solución: docker exec mycontainer cat /etc/resolv.conf xunto á lista de resolutores do anfitrión.

Un contedor que lista un resolutor público mentres o anfitrión lista un interno resolverá os nomes públicos e fallará cos internos. Ese reparto é a sinatura deste problema.

Opción A: pasar o resolutor do túnel por contedor

Docker acepta axustes de DNS por contedor, que é o cambio máis pequeno que funciona. Primeiro le as direccións do resolutor da VPN: scutil --dns en macOS, resolvectl status ou a saída de estado do propio cliente en Linux. Despois arranca o contedor con elas, por exemplo docker run --dns 192.168.2.1 --dns 192.168.123.1 myimage. En Compose o mesmo axuste é unha lista baixo o servizo, onde vive no control de versións en lugar do historial de shell de alguén.

Unha matriz dns en /etc/docker/daemon.json aplícase a cada contedor novo, o que soa máis ordenado e non o é. Tamén se aplica cando o túnel está caído, e entón un resolutor accesible só a través da VPN rompe as descargas de imaxes normais. Os axustes por contedor son máis doados de razoar e máis doados de desfacer.

Opción B: deixar que o contedor comparta a rede do anfitrión

A rede do anfitrión evita a copia por completo, porque o contedor usa o resolutor do anfitrión e o túnel do anfitrión. Tamén elimina o illamento de rede que probablemente querías, e non se comporta igual en Docker Desktop. En Linux é a opción pragmática para unha ferramenta dun só uso que debe resolver nomes internos.

Para as compilacións non se aplica ningunha das dúas opcións, xa que os pasos de compilación non herdan os indicadores de execución. Compila coa rede do anfitrión onde a plataforma o permita, ou mantén a instalación de dependencias nunha etapa que non necesite o túnel.

O que ningunha das dúas opcións arranxa

Unha dirección DNS é inútil se o contedor non ten ruta cara a ela. O resolutor da VPN adoita estar dentro do espazo de direccións do túnel, así que o contedor necesita un camiño cara a ese prefixo. A ponte predeterminada de Docker normalmente encamiña cara a fóra a través do anfitrión, o que abonda cando o anfitrión ten a ruta do túnel e o reenvío está activado. As redes ponte personalizadas cos seus propios rangos de direccións poden chocar coa subrede da VPN, e entón as consultas van a outro sitio por completo.

Comproba a subrede da rede de Docker contra a subrede da VPN antes de depurar o resolutor en si. A superposición produce un fallo que parece exactamente un servidor DNS roto.

Verifica dentro do contedor

Proba con getent hosts db.internal dentro do contedor en lugar de cun navegador ou unha contorna de execución de linguaxe, porque esas aplican a súa propia política de DNS e a súa propia caché. Se getent resolve o nome e a aplicación segue fallando, o resolutor xa é correcto e o problema restante está na capa de aplicación. Se non o resolve, o paso de DNS non está rematado.

Volve crear o contedor despois de cambiar os seus axustes de DNS. Editar /etc/resolv.conf dentro dun contedor en marcha desaparece con el e agocha o problema de configuración exactamente durante o tempo que alguén tarda en reinicialo.