Deling af en VPN-containers netværk: hvad sker der med DNS

Deling af en VPN-containers netværksnavnerum giver din applikation tunnellens grænseflader og ruter. Det giver den ikke tunnellens resolver, eller en sammenlagt kopi af noget andet på værten. Det hul giver en meget specifik fejl: offentlige navne slår op, interne navne gør ikke, og den app, der fejler, ser ud til at bruge den forkerte DNS-server, fordi det gør den. Reparationen er normalt mindre, end diagnosen antyder.

Trin 1: Test fra appen, ikke fra værten

Kør opslaget inde i containeren med problemet, ikke på værten og ikke i en browser. docker exec app-container getent hosts db.internal besvarer det eneste spørgsmål, der betyder noget: hvad denne proces' resolver returnerer.

Hvis værten slår navnet op, og containeren ikke gør, har du fundet fejlen. Alt derefter er at vælge en understøttet måde at rette den på.

Trin 2: Læs runtimeens understøttede model

Dockers netværksdokumentation registrerer begrænsninger for DNS-flag til containere, der deler en anden containers netværkstilstand. I Compose network_mode: service:vpn binder appen til VPN-containerens navnerum, og per tjeneste dns opfører indstillingerne sig ikke, som de gør for en almindelig tjeneste. Den opløsning, du får, er den, det delte navnerum har.

Brugerdefinerede bro-netværk bruger også Dockers indbyggede DNS anderledes end standardbroen. Det er derfor, en dns klausul kopieret fra et fungerende bro-eksempel kan gøre absolut intet i en delt stak. Kontrollér ordningen, før du kopierer klausulen.

En loopback-adresse henviser altid til den relevante netværkskontekst. Inde i et delt navnerum er 127.0.0.1 ikke værtens resolver.

Trin 3: Følg forespørgslen til dens modtager

Læs appens resolver-konfiguration, derefter enhver applikationsspecifik krypteret DNS, som appen leverer, fordi en app, der kører sin egen resolver, ignorerer den fil, du redigerede. Kontrollér derefter, om den valgte resolver kan nås under VPN'ens ruter og firewallpolitik. En resolveradresse på den anden side af tunnelen er ubrugelig, hvis navnerummet ikke har en rute til den. Bekræft modtageren, før du redigerer nogen fil.

En IP-kontrolside i en browser kan ikke fortælle, hvor navneforespørgslerne gik hen. Den fortæller, hvor én HTTP-forbindelse gik hen.

Trin 4: Ret de to fejlklasser forskelligt

Hvis tjenestenavne fejler, mens offentlige navne virker, er problemet tjenesteopdagelse inde i containernes netværk, ikke listen over offentlige resolvere. Ændring af hver offentlig DNS-adresse opretter ikke poster, som netværkets opdagelsesmekanisme aldrig er blevet bedt om.

Hvis begge klasser fejler, start med tilgængelighed til resolveren. Hvis kun én fejler, start med opdagelsesmekanismen. De to har forskellige ejere, og derfor dækker én reparation aldrig begge.

Trin 5: Test igen efter genskabelse

Ændr konfigurationen via runtimeens understøttede mekanisme, og genskab derefter containerne i stedet for at redigere filer inde i en kørende. Test et nyt privat navn, et nyt offentligt navn og den applikationsanmodning, der følger opslaget. En ændring i /etc/resolv.conf inde i en container forsvinder ved genskabelse og vil overbevise dig om, at rettelsen virkede, når den ikke gjorde.

Notér resolverens ejer og det forventede navnerum ved siden af den delte netværksdefinition. Den næste person får brug for begge.