VPN-konteineri võrgu jagamine: mis juhtub DNS-iga

VPN-konteineri võrgu nimeruumi jagamine annab sinu rakendusele tunneli liidesed ja marsruudid. See ei anna sellele tunneli resolverit, ega ühendatud koopiat millestki muust hostil. See lünk tekitab väga konkreetse tõrke: avalikud nimed lahenevad, sisemised mitte, ja tõrkuv rakendus näeb välja nagu kasutaks see vale DNS-serverit, sest ta kasutabki. Parandus on tavaliselt väiksem, kui diagnoos vihjab.

Samm 1: Testi rakendusest, mitte hostilt

Käivita otsing probleemse konteineri sees, mitte hostil ja mitte brauseris. docker exec app-container getent hosts db.internal vastab ainsale olulisele küsimusele: mida selle protsessi resolver tagastab.

Kui host lahendab nime ja konteiner mitte, oled vea leidnud. Kõik edasine on toetatud parandusviisi valimine.

Samm 2: Loe runtime'i toetatud mudelit

Dockeri võrgudokumentatsioon kirjeldab piiranguid DNS-lippudele konteineritele, mis jagavad teise konteineri võrgurežiimi. Compose'is network_mode: service:vpn seob rakenduse VPN-konteineri nimeruumiga ja iga teenuse puhul dns ei käitu seaded nii nagu tavalise teenuse puhul. Lahendus, mille saad, on see, mis jagatud nimeruumil on.

Kasutaja määratud sildvõrgud kasutavad Dockeri sisseehitatud DNS-i samuti teisiti kui vaikesild. Seetõttu ei pruugi dns töötavast sillanäitest kopeeritud klausel jagatud stackis üldse midagi teha. Kontrolli lahendust enne klausli kopeerimist.

Loopback-aadress viitab alati asjaomasele võrgukontekstile. Jagatud nimeruumi sees 127.0.0.1 ei ole hosti resolver.

Samm 3: Jälgi päringut selle saajani

Loe rakenduse resolveri konfiguratsiooni, seejärel mis tahes rakendusepõhist krüpteeritud DNS-i, mille rakendus kaasa toob, sest oma resolverit käitav rakendus eirab faili, mida sa muutsid. Seejärel kontrolli, kas valitud resolver on VPN-i marsruutide ja tulemüüri poliitika all kättesaadav. Resolveri aadress tunnelist teisel pool on kasutu, kui nimeruumil pole sinna marsruuti. Kinnita saaja enne mis tahes faili muutmist.

Brauseri IP-kontrolli leht ei saa öelda, kuhu nimepäringud läksid. See ütleb, kuhu läks üks HTTP-ühendus.

Samm 4: Paranda kahte tõrkeklassi erinevalt

Kui teenusenimed tõrkuvad, samal ajal kui avalikud nimed töötavad, on probleem konteinerivõrgu sisemises teenuseavastuses, mitte avalike resolverite loendis. Iga avaliku DNS-aadressi muutmine ei loo kirjeid, mida võrgu avastusmehhanismilt pole kunagi küsitud.

Kui mõlemad klassid tõrkuvad, alusta resolveri kättesaadavusest. Kui tõrkub ainult üks, alusta avastusmehhanismist. Need kaks on erinevate omanikega, seepärast ei kata üks parandus kunagi mõlemat.

Samm 5: Testi uuesti pärast uuesti loomist

Muuda konfiguratsiooni runtime'i toetatud mehhanismi kaudu, seejärel loo konteinerid uuesti, selle asemel et muuta faile töötava konteineri sees. Testi värsket privaatset nime, värsket avalikku nime ja rakenduse päringut, mis otsingule järgneb. Muudatus failis /etc/resolv.conf konteineri sees kaob uuesti loomisel ja veenab sind, et parandus töötas, kuigi see ei töötanud.

Märgi resolveri omanik ja oodatav nimeruum jagatud võrgu definitsiooni kõrvale. Järgmine inimene vajab mõlemat.