Miks Dockeri konteinerid ignoreerivad VPN-i DNS-i lahendajat

VPN töötab, brauser jõuab sisemistele saitidele, ja konteiner ei suuda ikka samu nimesid lahendada. Paketi paigaldus sureb nime lahendamise veaga nagu EAI_AGAIN, või rakendus ei leia andmebaasi hosti, mille hostmasin ilma ühegi kaebuseta lahendab. Konteiner ei kasuta lahendajat, mille VPN paigaldas. Docker kopeeris hosti lahendaja konfiguratsiooni konteineri loomise hetkel, ja pärast seda ei kopeerinud seda miski uuesti.

Kaks lahendaja vaadet ühel masinal

Linuxis annab Docker igale konteinerile loomise hetkel koopia hosti lahendaja konfiguratsioonist, filtreerib välja loopback-aadressid ja käitab sisseehitatud DNS-serverit aadressil 127.0.0.11, mis edastab päringud väljapoole. VPN-klient, mis kirjutab /etc/resolv.conf üle pärast konteineri käivitumist, ei muuda selle sees midagi. Konteineri taaskäivitamine aitab ainult siis, kui hosti lahendaja on sellel hetkel juhuslikult õige.

Docker Desktop macOS-il või Windowsil lisab kihi, sest deemon elab virtuaalmasinas. Hosti VPN-i lahendaja ei pruugi sellele VM-ile kunagi nähtav olla, seega taaskäivitamine ei muuda üldse midagi. Võrrelge kahte vaadet enne paranduse valimist: docker exec mycontainer cat /etc/resolv.conf hosti lahendajate loendi kõrval.

Konteiner, mis loetleb avalikku lahendajat, samal ajal kui host loetleb sisemist, lahendab avalikud nimed ja ebaõnnestub sisemiste puhul. See lõhe ongi selle probleemi allkiri.

Valik A: edasta tunnelilahendaja konteineri kaupa

Docker võtab vastu DNS-i seadeid konteineri kaupa, ja see on väikseim muudatus, mis töötab. Kõigepealt lugege VPN-i lahendaja aadressid: scutil --dns macOS-il, resolvectl status või kliendi enda olekuväljund Linuxis. Seejärel käivitage konteiner nendega, näiteks docker run --dns 192.168.2.1 --dns 192.168.123.1 myimage. Compose'is on sama säte teenuse all olev loend, kus see elab versioonihalduses, mitte kellegi kestahistorias.

Massiiv dns failis /etc/docker/daemon.json kehtib iga uue konteineri kohta, mis kõlab korrastatumalt, kui see on. See kehtib ka siis, kui tunnel on maas, ja ainult VPN-i kaudu kättesaadav lahendaja rikub siis tavalise kujutise tõmbamise. Konteineripõhiseid seadeid on lihtsam põhjendada ja lihtsam tagasi võtta.

Valik B: lase konteineril hosti võrku jagada

Hosti võrk väldib koopiat täielikult, sest konteiner kasutab hosti lahendajat ja hosti tunnelit. See eemaldab ka võrguisolatsiooni, mida te tõenäoliselt soovisite, ja Docker Desktopi all ei käitu see samamoodi. Linuxis on see pragmaatiline valik ühekordse tööriista jaoks, mis peab sisemisi nimesid lahendama.

Buildide puhul ei kehti kumbki valik, sest build-sammud ei päri käitusaegseid lippe. Buildige hosti võrguga seal, kus platvorm seda lubab, või hoidke sõltuvuste paigaldus etapis, mis tunnelit ei vaja.

Mida kumbki valik ei paranda

DNS-aadress on kasutu, kui konteineril pole sinna marsruuti. VPN-i lahendaja asub tavaliselt tunneli aadressiruumis, seega vajab konteiner teed selle prefiksini. Dockeri vaikimisi sild marsruudib tavaliselt hosti kaudu välja, ja sellest piisab, kui hostil on tunneli marsruut ja edastamine on lubatud. Kohandatud sillavõrgud oma aadressibasseinidega võivad VPN-i alamvõrguga kokku põrgata, ja siis lähevad päringud hoopis mujale.

Kontrollige Dockeri võrgu alamvõrku VPN-i alamvõrgu vastu enne, kui hakkate lahendajat ennast siluma. Kattumine tekitab tõrke, mis näeb välja täpselt nagu katkine DNS-server.

Kontrollige konteineri sees

Testige konteineri sees käsuga getent hosts db.internal, mitte brauseri ega keelelise käituskeskkonnaga, sest need rakendavad oma DNS-poliitikat ja oma vahemälu. Kui getent lahendab nime ja rakendus ikka ebaõnnestub, on lahendaja nüüd korras ja ülejäänud probleem on rakenduse tasandil. Kui see ei lahenda, pole DNS-i samm lõpetatud.

Looge konteiner uuesti pärast selle DNS-i seadete muutmist. /etc/resolv.conf muutmine töötava konteineri sees kaob koos sellega ja peidab konfiguratsiooniprobleemi täpselt nii kauaks, kui kellelgi kulub selle taaskäivitamiseks.