Partajarea rețelei unui container VPN: ce se întâmplă cu DNS

Partajarea spațiului de nume de rețea al unui container VPN dă aplicației tale interfețele și rutele tunelului. El nu îi dă resolverul tunelului, nici o copie unificată a orice altceva de pe gazdă. Acest decalaj produce o defecțiune foarte specifică: numele publice se rezolvă, cele interne nu, iar aplicația care eșuează pare să folosească serverul DNS greșit, pentru că exact asta face. Reparația este de obicei mai mică decât sugerează diagnosticul.

Pasul 1: Testează din aplicație, nu de pe gazdă

Rulează căutarea în interiorul containerului care are problema, nu pe gazdă și nu într-un browser. docker exec app-container getent hosts db.internal răspunde la singura întrebare care contează: ce returnează resolverul acestui proces.

Dacă gazda rezolvă numele, iar containerul nu, ai găsit defecțiunea. Tot ce urmează este alegerea unei metode acceptate de a o repara.

Pasul 2: Citește modelul acceptat al runtime-ului

Documentația de rețea a Docker înregistrează restricții privind fanioanele DNS pentru containerele care partajează modul de rețea al altui container. În Compose network_mode: service:vpn leagă aplicația de spațiul de nume al containerului VPN, iar pentru fiecare serviciu dns setările nu se comportă ca într-un serviciu obișnuit. Rezolvarea pe care o obții este cea pe care o are spațiul de nume partajat.

Rețelele de punte definite de utilizator folosesc și ele DNS-ul încorporat al Docker diferit de puntea implicită. De aceea o dns clauză copiată dintr-un exemplu de punte funcțional poate să nu facă absolut nimic într-un stack partajat. Verifică aranjamentul înainte de a copia clauza.

O adresă de buclă se referă întotdeauna la contextul de rețea relevant. În interiorul unui spațiu de nume partajat, 127.0.0.1 nu este resolverul gazdei.

Pasul 3: Urmărește interogarea până la destinatar

Citește configurația resolverului aplicației, apoi orice DNS criptat specific aplicației pe care aceasta îl aduce, pentru că o aplicație care rulează propriul resolver ignoră fișierul pe care l-ai editat. Apoi verifică dacă resolverul ales este accesibil sub rutele și politica de firewall ale VPN-ului. O adresă de resolver de cealaltă parte a tunelului este inutilă dacă spațiul de nume nu are rută către ea. Confirmă destinatarul înainte de a edita orice fișier.

O pagină de verificare IP din browser nu îți poate spune unde au mers interogările de nume. Îți spune unde a mers o conexiune HTTP.

Pasul 4: Repară cele două clase de defecțiune diferit

Dacă numele de serviciu eșuează în timp ce numele publice funcționează, problema este descoperirea serviciilor în interiorul rețelei de containere, nu lista resolverelor publice. Schimbarea fiecărei adrese DNS publice nu va crea înregistrări pe care mecanismul de descoperire al rețelei nu a fost niciodată rugat să le creeze.

Dacă ambele clase eșuează, începe cu accesibilitatea resolverului. Dacă doar una eșuează, începe cu mecanismul de descoperire. Cele două au proprietari diferiți, de aceea o singură reparație nu le acoperă niciodată pe amândouă.

Pasul 5: Retestează după recreare

Schimbă configurația prin mecanismul acceptat al runtime-ului, apoi recreează containerele în loc să editezi fișiere într-unul care rulează. Testează un nume privat nou, un nume public nou și cererea aplicației care urmează căutării. O modificare în /etc/resolv.conf în interiorul unui container dispare la recreare și te va convinge că reparația a funcționat când nu a făcut-o.

Notează proprietarul resolverului și spațiul de nume așteptat lângă definiția rețelei partajate. Următoarea persoană va avea nevoie de ambele.