Het netwerk van een VPN-container delen: wat er met DNS gebeurt

Het delen van de netwerknaamruimte van een VPN-container geeft je applicatie de interfaces en routes van de tunnel. Het geeft hem niet de resolver van de tunnel, of een samengevoegde kopie van iets anders op de host. Dat gat veroorzaakt een heel specifieke fout: openbare namen worden opgelost, interne niet, en de app die faalt lijkt de verkeerde DNS-server te gebruiken, omdat dat zo is. De reparatie is meestal kleiner dan de diagnose suggereert.

Stap 1: Test vanuit de app, niet vanaf de host

Voer de opzoeking uit in de container met het probleem, niet op de host en niet in een browser. docker exec app-container getent hosts db.internal beantwoordt de enige vraag die ertoe doet: wat de resolver van dit proces teruggeeft.

Als de host de naam oplost en de container niet, heb je de fout gevonden. Alles daarna is een ondersteunde manier kiezen om hem te repareren.

Stap 2: Lees het ondersteunde model van de runtime

Dockers netwerkdocumentatie vermeldt beperkingen voor DNS-vlaggen bij containers die de netwerkmodus van een andere container delen. In Compose network_mode: service:vpn bindt de app aan de naamruimte van de VPN-container, en per dienst dns gedragen de instellingen zich niet zoals bij een gewone dienst. De resolutie die je krijgt, is degene die de gedeelde naamruimte heeft.

Door gebruikers gedefinieerde bridgenetwerken gebruiken de ingebouwde DNS van Docker ook anders dan de standaardbrug. Daarom kan een dns clausule die uit een werkend brugvoorbeeld is gekopieerd in een gedeelde stack helemaal niets doen. Controleer de opzet voordat je de clausule kopieert.

Een loopbackadres verwijst altijd naar de relevante netwerkcontext. Binnen een gedeelde naamruimte is 127.0.0.1 niet de resolver van de host.

Stap 3: Volg de query tot de ontvanger

Lees de resolverconfiguratie van de app en daarna elke applicatiespecifieke versleutelde DNS die de app meebrengt, want een app die zijn eigen resolver draait, negeert het bestand dat je hebt bewerkt. Controleer vervolgens of de gekozen resolver bereikbaar is onder de routes en het firewallbeleid van de VPN. Een resolveradres aan de andere kant van de tunnel is nutteloos als de naamruimte er geen route naartoe heeft. Bevestig de ontvanger voordat je een bestand bewerkt.

Een IP-controlepagina in een browser kan je niet vertellen waar naamquery's naartoe gingen. Hij vertelt waar één HTTP-verbinding naartoe ging.

Stap 4: Repareer de twee foutklassen verschillend

Als servicenamen falen terwijl openbare namen werken, zit het probleem in servicedetectie binnen het containernetwerk, niet in de lijst met openbare resolvers. Elk openbaar DNS-adres wijzigen maakt geen records aan waar het detectiemechanisme van het netwerk nooit om is gevraagd.

Als beide klassen falen, begin dan met bereikbaarheid van de resolver. Als er maar één faalt, begin dan met het detectiemechanisme. De twee hebben verschillende eigenaren, daarom dekt één reparatie nooit beide.

Stap 5: Test opnieuw na hercreatie

Wijzig de configuratie via het ondersteunde mechanisme van de runtime en maak daarna de containers opnieuw aan in plaats van bestanden in een draaiende container te bewerken. Test een nieuwe privénaam, een nieuwe openbare naam en het applicatieverzoek dat op de opzoeking volgt. Een wijziging in /etc/resolv.conf in een container verdwijnt bij hercreatie en zal je ervan overtuigen dat de reparatie werkte terwijl dat niet zo was.

Noteer de eigenaar van de resolver en de verwachte naamruimte naast de definitie van het gedeelde netwerk. De volgende persoon heeft beide nodig.