Deel ’n VPN-houer se netwerk: wat met DNS gebeur

Deel van ’n VPN-houer se netwerknaamruimte gee jou toepassing die tonnel se koppelvlakke en roetes. Dit gee dit nie die tonnel se resolver nie, of ’n saamgevoegde kopie van enigiets anders op die gasheer nie. Daardie gaping veroorsaak ’n baie spesifieke fout: publieke name los op, interne name nie, en die app wat misluk lyk of dit die verkeerde DNS-bediener gebruik, want dit doen. Die herstel is gewoonlik kleiner as wat die diagnose voorstel.

Stap 1: Toets vanuit die app, nie die gasheer nie

Voer die opsoek uit binne die houer met die probleem, nie op die gasheer en nie in ’n blaaier nie. docker exec app-container getent hosts db.internal beantwoord die enigste vraag wat saak maak, naamlik wat hierdie proses se resolver teruggee.

As die gasheer die naam oplos en die houer nie, het jy die fout gevind. Alles hierna is om ’n ondersteunde manier te kies om dit reg te maak.

Stap 2: Lees die runtime se ondersteunde model

Docker se netwerkdokumentasie teken beperkinge aan op DNS-vlae vir houers wat ’n ander houer se netwerkmodus deel. In Compose network_mode: service:vpn bind die app aan die VPN-houer se naamruimte, en per diens dns gedra die instellings hulle nie soos by ’n gewone diens nie. Die oplossing wat jy kry, is die een wat die gedeelde naamruimte het.

Gebruiker-gedefinieerde brugnetwerke gebruik ook Docker se ingeboude DNS anders as die standaardbrug. Dit is waarom ’n dns strofe wat uit ’n werkende brugvoorbeeld gekopieer is, glad niks in ’n gedeelde stapel kan doen nie. Kyk na die reëling voordat jy die strofe kopieer.

’n Loopback-adres verwys altyd na die betrokke netwerkkonteks. Binne ’n gedeelde naamruimte is 127.0.0.1 nie die gasheer se resolver nie.

Stap 3: Volg die navraag na sy ontvanger

Lees die app se resolver-konfigurasie, dan enige toepassing-spesifieke geënkripteerde DNS wat die app meebring, want ’n app wat sy eie resolver bestuur, ignoreer die lêer wat jy geredigeer het. Kyk dan of die gekose resolver bereikbaar is onder die VPN se roetes en firewallbeleid. ’n Resolver-adres aan die ander kant van die tonnel is nutteloos as die naamruimte geen roete daarheen het nie. Bevestig die ontvanger voordat jy enige lêer redigeer.

’n Blaaier se IP-kontroleblad kan nie sê waarheen naamsnavrae gegaan het nie. Dit sê waarheen een HTTP-verbinding gegaan het.

Stap 4: Maak die twee foutklasse verskillend reg

As diensname misluk terwyl publieke name werk, is die probleem diensontdekking binne die houernetwerk, nie die publieke resolver-lys nie. Om elke publieke DNS-adres te verander, sal nie rekords skep waarvoor die netwerk se ontdekkingsmeganisme nooit gevra is nie.

As albei klasse misluk, begin met bereikbaarheid na die resolver. As net een misluk, begin met die ontdekkingsmeganisme. Die twee het verskillende eienaars, en daarom dek een herstel nooit albei nie.

Stap 5: Toets weer ná herskeping

Verander die konfigurasie deur die runtime se ondersteunde meganisme en herskep dan die houers eerder as om lêers binne ’n lopende een te redigeer. Toets ’n vars private naam, ’n vars publieke naam en die toepassingsversoek wat op die opsoek volg. ’n Wysiging aan /etc/resolv.conf binne ’n houer verdwyn met herskeping en sal jou oortuig dat die regstelling gewerk het toe dit nie het nie.

Teken die resolver-eienaar en die verwagte naamruimte langs die gedeelde netwerkdefinisie aan. Die volgende persoon sal albei nodig hê.