Dela en VPN-containers nätverk: vad som händer med DNS

Delning av nätverksnamnutrymmet för en VPN-container ger din applikation tunnelns gränssnitt och rutter. Den ger den inte tunnelns resolver, eller en sammanslagen kopia av något annat på värden. Den luckan ger ett mycket specifikt fel: offentliga namn löses upp, interna gör det inte, och appen som misslyckas ser ut att använda fel DNS-server, eftersom det gör den. Reparationen är vanligtvis mindre än diagnosen antyder.

Steg 1: Testa från appen, inte från värden

Kör uppslaget inuti containern som har problemet, inte på värden och inte i en webbläsare. docker exec app-container getent hosts db.internal svarar på den enda fråga som spelar roll: vad den här processens resolver returnerar.

Om värden löser namnet och containern inte gör det, har du hittat felet. Allt därefter är att välja ett stött sätt att åtgärda det.

Steg 2: Läs runtimeens stödda modell

Dockers nätverksdokumentation registrerar begränsningar för DNS-flaggor för containrar som delar en annan containers nätverksläge. I Compose network_mode: service:vpn binder appen till VPN-containerns namnutrymme, och per tjänst dns beter sig inställningarna inte som för en vanlig tjänst. Upplösningen du får är den som det delade namnutrymmet har.

Användardefinierade bryggnätverk använder också Dockers inbyggda DNS annorlunda än standardbryggan. Därför kan en dns klausul kopierad från ett fungerande brygg-exempel göra absolut ingenting i en delad stack. Kontrollera ordningen innan du kopierar klausulen.

En loopback-adress hänvisar alltid till relevant nätverkskontext. Inuti ett delat namnutrymme är 127.0.0.1 inte värdens resolver.

Steg 3: Följ frågan till mottagaren

Läs appens resolverkonfiguration och sedan eventuell applikationsspecifik krypterad DNS som appen levererar, eftersom en app som kör sin egen resolver ignorerar filen du redigerade. Kontrollera sedan om den valda resolvern är nåbar under VPN:ens rutter och brandväggsprincip. En resolveradress på andra sidan tunneln är värdelös om namnutrymmet inte har någon rutt dit. Bekräfta mottagaren innan du redigerar någon fil.

En IP-kontrollsida i en webbläsare kan inte berätta vart namnfrågorna tog vägen. Den berättar vart en HTTP-anslutning tog vägen.

Steg 4: Åtgärda de två felklasserna olika

Om tjänstenamn misslyckas medan offentliga namn fungerar, ligger problemet i tjänsteupptäckt inuti containernätverket, inte i listan över offentliga resolvers. Att ändra varje offentlig DNS-adress skapar inte poster som nätverkets upptäcktsmekanism aldrig har blivit ombedd att skapa.

Om båda klasserna misslyckas, börja med nåbarheten till resolvern. Om bara en misslyckas, börja med upptäcktsmekanismen. De två har olika ägare, därför täcker en reparation aldrig båda.

Steg 5: Testa igen efter återskapande

Ändra konfigurationen via runtimeens stödda mekanism och återskapa sedan containrarna i stället för att redigera filer inuti en som körs. Testa ett nytt privat namn, ett nytt offentligt namn och applikationsbegäran som följer uppslaget. En ändring i /etc/resolv.conf inuti en container försvinner vid återskapande och kommer att övertyga dig om att reparationen fungerade när den inte gjorde det.

Anteckna resolverns ägare och det förväntade namnutrymmet bredvid definitionen av det delade nätverket. Nästa person behöver båda.