Hvorfor Docker-containere ignorerer VPN-ens DNS-resolver

VPN-en er oppe, nettleseren når interne sider, og containeren kan fortsatt ikke slå opp de samme navnene. En pakkeinstallasjon dør med en navneoppslagsfeil som EAI_AGAIN, eller et program finner ikke en databasevert som vertsmaskinen slår opp uten klager. Containeren bruker ikke resolveren som VPN-en installerte. Docker kopierte vertens resolverkonfigurasjon da containeren ble opprettet, og ingenting kopierte den igjen etterpå.

To resolver-visninger på én maskin

På Linux gir Docker hver container en kopi av vertens resolverkonfigurasjon ved opprettelsen, filtrerer bort loopback-adresser og kjører en innebygd DNS-server på 127.0.0.11 som videresender spørringer ut. En VPN-klient som skriver om /etc/resolv.conf etter at containeren er startet, endrer ingenting inni den. Å starte containeren på nytt hjelper bare hvis vertens resolver tilfeldigvis er riktig i det øyeblikket.

Docker Desktop på macOS eller Windows legger til et lag, fordi daemonen bor i en virtuell maskin. Vertens VPN-resolver er kanskje aldri synlig for den VM-en, så en omstart endrer ingenting i det hele tatt. Sammenlign de to visningene før du velger en løsning: docker exec mycontainer cat /etc/resolv.conf ved siden av vertens resolverliste.

En container som lister en offentlig resolver mens verten lister en intern, vil slå opp offentlige navn og feile på interne. Den delingen er signaturen på dette problemet.

Alternativ A: send tunnelresolveren videre per container

Docker godtar DNS-innstillinger per container, og det er den minste endringen som virker. Les først VPN-ens resolveradresser: scutil --dns på macOS, resolvectl status eller klientens egen statusutskrift på Linux. Start deretter containeren med dem, for eksempel docker run --dns 192.168.2.1 --dns 192.168.123.1 myimage. I Compose er den samme innstillingen en liste under tjenesten, der den bor i versjonskontroll i stedet for i noens shell-historikk.

En dns-matrise i /etc/docker/daemon.json gjelder for hver ny container, noe som høres ryddigere ut enn det er. Den gjelder også når tunnelen er nede, og en resolver som bare kan nås via VPN-en ødelegger da vanlige image-hentinger. Innstillinger per container er lettere å begrunne og lettere å angre.

Alternativ B: la containeren dele vertens nettverk

Vertsnettverk omgår kopien helt, fordi containeren bruker vertens resolver og vertens tunnel. Det fjerner også nettverksisoleringen du sannsynligvis ønsket, og det oppfører seg ikke likt under Docker Desktop. På Linux er det det pragmatiske valget for et engangsverktøy som må slå opp interne navn.

For bygg gjelder ingen av alternativene, siden byggesteg ikke arver kjøretidsflagg. Bygg med vertsnettverk der plattformen tillater det, eller hold avhengighetsinstallasjonen i et steg som ikke trenger tunnelen.

Hva ingen av alternativene fikser

En DNS-adresse er ubrukelig hvis containeren ikke har rute til den. VPN-resolveren sitter vanligvis inne i tunnelens adresserom, så containeren trenger en vei til det prefikset. Dockers standardbro ruter vanligvis ut gjennom verten, og det er nok når verten har tunnelruten og videresending er slått på. Egendefinerte bronettverk med egne adressepuljer kan kollidere med VPN-ens subnett, og da går spørringene et helt annet sted.

Sjekk Docker-nettverkets subnett mot VPN-ens subnett før du feilsøker selve resolveren. Overlapp gir en feil som ser nøyaktig ut som en ødelagt DNS-server.

Verifiser inne i containeren

Test med getent hosts db.internal inne i containeren i stedet for med en nettleser eller en språkruntime, fordi de bruker sin egen DNS-policy og sin egen hurtigbuffer. Hvis getent slår opp navnet og programmet fortsatt feiler, er resolveren nå riktig og det gjenværende problemet er på programnivå. Hvis den ikke slår det opp, er DNS-steget ikke ferdig.

Gjenskap containeren etter at du har endret DNS-innstillingene. Redigering av /etc/resolv.conf inne i en kjørende container forsvinner med den og skjuler konfigurasjonsproblemet nøyaktig så lenge som noen trenger for å starte den på nytt.