D'Netzwierk vun engem VPN-Container deelen: wat geschitt mat DNS

D'Deelen vum Netzwierk-Nummraum vun engem VPN-Container gëtt Ärer Applikatioun d'Interfacen an d'Routen vum Tunnel. Et gëtt hir net de Resolver vum Tunnel, an och keng zesummegesate Kopie vun eppes anescht um Host. Dës Lück produzéiert e ganz spezifesche Fehler: ëffentlech Nimm ginn opgeléist, intern net, an d'App, déi feelt, gesäit aus wéi wann se de falschen DNS-Server benotzt, well dat ass wat se mécht. D'Reparatur ass meeschtens méi kleng wéi d'Diagnos et suggeréiert.

Schrëtt 1: Test vum App, net vum Host

Fuert d'Opzielung am Container aus, deen de Problem huet, net um Host an net am Browser. docker exec app-container getent hosts db.internal äntwert op déi eenzeg Fro, déi wichteg ass: wat de Resolver vun dësem Prozess zeréckgëtt.

Wann den Host den Numm opgeléist an de Container net, hutt Dir de Fehler fonnt. Alles duerno ass eng ënnerstëtzte Manéier ze wielen, fir en ze reparéieren.

Schrëtt 2: Liest de ënnerstëtzte Modell vum Runtime

Docker seng Netzwierk-Dokumentatioun registréiert Restriktiounen op DNS-Flags fir Containeren, déi de Netzwierkmodus vun engem anere Container deelen. Am Compose network_mode: service:vpn bäint d'App un den Nummraum vum VPN-Container, a pro Service dns behuelen d'Astellungen sech net wéi bei engem gewéinleche Service. D'Léisung, déi Dir kritt, ass déi, déi den gedeelten Nummraum huet.

Benotzerdefinéiert Brécke-Netzwierker benotzen och Docker seng agebaut DNS anescht wéi d'Standardbréck. Dofir kann eng dns Klausel, déi aus engem funktionéierende Brécke-Beispill kopéiert gouf, an engem gedeelte Stack guer näischt maachen. Kontrolléiert d'Uerdnung, ier Dir d'Klausel kopéiert.

Eng Loopback-Adress bezitt sech ëmmer op de relevante Netzwierkkontext. Bannen an engem gedeelten Nummraum ass 127.0.0.1 net de Resolver vum Host.

Schrëtt 3: Follegt der Ufro bis zu hirem Empfänger

Liest d'Resolver-Konfiguratioun vun der App, dann all App-spezifeschen verschlësselten DNS, deen d'App matbréngt, well eng App, déi hire eegene Resolver bedreift, ignoréiert d'Datei, déi Dir geännert hutt. Dann kontrolléiert, ob de gewielte Resolver ënner de Routen an der Firewall-Politik vum VPN erreechbar ass. Eng Resolver-Adress op der anerer Säit vum Tunnel ass nëtzlos, wann den Nummraum keng Route dohinner huet. Bestätegt den Empfänger, ier Dir eng Datei ännert.

Eng IP-Kontrollsäit am Browser kann Iech net soen, wou d'Nimmufroe gaange sinn. Si seet Iech, wou eng HTTP-Verbindung gaangen ass.

Schrëtt 4: Reparéiert déi zwou Fehlerklassen ënnerschiddlech

Wann Service-Nimm feelen, während ëffentlech Nimm funktionéieren, ass de Problem d'Service-Entdeckung bannen an der Containers-Netzwierk, net d'Lëscht vun ëffentleche Resolveren. All ëffentlech DNS-Adress z'änneren schaaft keng Enregistrementer, déi vum Entdeckungsmechanismus vum Netzwierk ni gefrot goufen.

Wann déi zwou Klassen feelen, fänkt mat der Erreechbarkeet vum Resolver un. Wann nëmmen eng feelt, fänkt mam Entdeckungsmechanismus un. Déi zwou hunn ënnerschiddlech Propriétaires, dofir deckt eng Reparatur ni béides of.

Schrëtt 5: Testt nom Neischafen erëm

Ännert d'Konfiguratioun iwwer den ënnerstëtzte Mechanismus vum Runtime, schaaft dann d'Containeren nei, amplaz Dateien an engem lafenden ze änneren. Testt en neien private Numm, en neien ëffentlechen Numm an d'App-Ufro, déi op d'Opzielung follegt. Eng Ännerung un /etc/resolv.conf bannen an engem Container verschwënnt beim Neischafen a wäert Iech iwwerzeegen, datt d'Reparatur funktionéiert huet, wéi se et net huet.

Notéiert de Propriétaire vum Resolver an den erwaarten Nummraum nieft der Definitioun vum gedeelte Netzwierk. Déi nächst Persoun wäert béides brauchen.