Dele nettverket til en VPN-container: hva skjer med DNS

Deling av nettverksnavnerommet til en VPN-container gir applikasjonen din tunnelens grensesnitt og ruter. Det gir den ikke tunnelens resolver, eller en sammenslått kopi av noe annet på verten. Det gapet gir en svært spesifikk feil: offentlige navn slås opp, interne navn gjør det ikke, og appen som feiler ser ut til å bruke feil DNS-server, fordi det gjør den. Reparasjonen er vanligvis mindre enn diagnosen antyder.

Trinn 1: Test fra appen, ikke fra verten

Kjør oppslaget inne i containeren som har problemet, ikke på verten og ikke i en nettleser. docker exec app-container getent hosts db.internal svarer på det eneste spørsmålet som betyr noe: hva denne prosessens resolver returnerer.

Hvis verten slår opp navnet og containeren ikke gjør det, har du funnet feilen. Alt etter dette er å velge en støttet måte å rette den på.

Trinn 2: Les runtimeens støttede modell

Dockers nettverksdokumentasjon registrerer begrensninger på DNS-flagg for containere som deler en annen containers nettverksmodus. I Compose network_mode: service:vpn binder appen til VPN-containerens navnerom, og per tjeneste dns oppfører innstillingene seg ikke slik de gjør for en vanlig tjeneste. Oppslaget du får, er det det delte navnerommet har.

Brukerdefinerte bro-nettverk bruker også Dockers innebygde DNS annerledes enn standardbroen. Derfor kan en dns klausul kopiert fra et fungerende bro-eksempel gjøre absolutt ingenting i en delt stabel. Kontroller ordningen før du kopierer klausulen.

En loopback-adresse viser alltid til den relevante nettverkskonteksten. Inne i et delt navnerom er 127.0.0.1 ikke vertens resolver.

Trinn 3: Følg spørringen til mottakeren

Les appens resolver-konfigurasjon, deretter enhver applikasjonsspesifikk kryptert DNS som appen leverer med, fordi en app som kjører sin egen resolver, ignorerer filen du redigerte. Sjekk deretter om den valgte resolveren er tilgjengelig under VPN-ens ruter og brannmurpolitikk. En resolveradresse på den andre siden av tunnelen er ubrukelig hvis navnerommet ikke har rute dit. Bekreft mottakeren før du redigerer noen fil.

En IP-kontrollside i en nettleser kan ikke fortelle deg hvor navnespørringene gikk. Den forteller hvor én HTTP-tilkobling gikk.

Trinn 4: Rett de to feilklassene ulikt

Hvis tjenestenavn feiler mens offentlige navn virker, er problemet tjenesteoppdagelse inne i containernettverket, ikke listen over offentlige resolvere. Å endre hver offentlig DNS-adresse skaper ikke poster som nettverkets oppdagelsesmekanisme aldri er blitt bedt om.

Hvis begge klassene feiler, start med tilgjengelighet til resolveren. Hvis bare én feiler, start med oppdagelsesmekanismen. De to har forskjellige eiere, derfor dekker én reparasjon aldri begge.

Trinn 5: Test på nytt etter ny oppretting

Endre konfigurasjonen via runtimeens støttede mekanisme, og opprett deretter containerne på nytt i stedet for å redigere filer inne i en som kjører. Test et nytt privat navn, et nytt offentlig navn og applikasjonsforespørselen som følger oppslaget. En endring i /etc/resolv.conf inne i en container forsvinner ved ny oppretting og vil overbevise deg om at reparasjonen virket, når den ikke gjorde det.

Noter resolverens eier og det forventede navnerommet ved siden av definisjonen av det delte nettverket. Den neste personen trenger begge.