Dele nettverket til ein VPN-container: kva som skjer med DNS

Deling av nettverksnamnerommet til ein VPN-container gjev applikasjonen din grensesnitta og rutene til tunnelen. Det gjev han ikkje resolveren til tunnelen, eller ein samanslått kopi av noko anna på verten. Det gapet gjev ein svært spesifikk feil: offentlege namn blir slått opp, interne namn blir det ikkje, og appen som feilar ser ut til å bruke feil DNS-server, fordi det gjer han. Reparasjonen er vanlegvis mindre enn diagnosen antydar.

Steg 1: Test frå appen, ikkje frå verten

Køyr oppslaget inne i containeren som har problemet, ikkje på verten og ikkje i ein nettlesar. docker exec app-container getent hosts db.internal svarar på det einaste spørsmålet som tel: kva denne prosessen sin resolver returnerer.

Viss verten slår opp namnet og containeren ikkje gjer det, har du funne feilen. Alt etter dette er å velje ein støtta måte å rette han på.

Steg 2: Les den støtta modellen til runtime

Dockers nettverksdokumentasjon registrerer avgrensingar på DNS-flagg for containarar som deler nettverksmodusen til ein annan container. I Compose network_mode: service:vpn bind appen til namnerommet til VPN-containeren, og per teneste dns oppfører innstillingane seg ikkje slik dei gjer for ei vanleg teneste. Oppslaget du får, er det det delte namnerommet har.

Brukardefinerte bru-nettverk brukar òg den innebygde DNS-en til Docker annleis enn standardbrua. Derfor kan ein dns klausul kopiert frå eit fungerande bru-døme gjere absolutt ingenting i ein delt stabel. Kontroller ordninga før du kopierer klausulen.

Ei loopback-adresse viser alltid til den relevante nettverkskonteksten. Inne i eit delt namnerom er 127.0.0.1 ikkje resolveren til verten.

Steg 3: Følg spørjinga til mottakaren

Les resolverkonfigurasjonen til appen, deretter kvar applikasjonsspesifikk kryptert DNS som appen leverer med, fordi ein app som køyrer sin eigen resolver, ignorerer fila du redigerte. Sjekk deretter om den valde resolveren er tilgjengeleg under rutene og brannmurpolitikken til VPN-en. Ei resolveradresse på den andre sida av tunnelen er ubrukeleg viss namnerommet ikkje har rute dit. Stadfest mottakaren før du redigerer noka fil.

Ei IP-kontrollside i ein nettlesar kan ikkje fortelje deg kvar namnspørjingane gjekk. Ho fortel kvar éi HTTP-tilkopling gjekk.

Steg 4: Rett dei to feilklassane ulikt

Viss tenestenamn feilar medan offentlege namn verkar, er problemet tenesteoppdaging inne i containernettverket, ikkje lista over offentlege resolverar. Å endre kvar offentleg DNS-adresse skapar ikkje postar som oppdagingsmekanismen til nettverket aldri er blitt bede om.

Viss begge klassane feilar, start med tilgjenge til resolveren. Viss berre éin feilar, start med oppdagingsmekanismen. Dei to har ulike eigarar, derfor dekkjer éin reparasjon aldri begge.

Steg 5: Test på nytt etter ny oppretting

Endre konfigurasjonen via den støtta mekanismen til runtime, og opprett deretter containerane på nytt i staden for å redigere filer inne i ein som køyrer. Test eit nytt privat namn, eit nytt offentleg namn og applikasjonsførespurnaden som følgjer oppslaget. Ei endring i /etc/resolv.conf inne i ein container forsvinn ved ny oppretting og vil overtyde deg om at reparasjonen verka, når han ikkje gjorde det.

Noter eigaren til resolveren og det forventa namnerommet ved sida av definisjonen av det delte nettverket. Den neste personen treng begge.