Pagbabahagi ng network ng isang VPN container: ano ang nangyayari sa DNS

Ang pagbabahagi ng network namespace ng isang VPN container ay nagbibigay sa app mo ng mga interface at ruta ng tunnel. Hindi nito ibinibigay sa app ang resolver ng tunnel, ni pinagsamang kopya ng anupamang iba sa host. Ang agwat na iyon ay gumagawa ng napakatiyak na pagkabigo: nareresolba ang mga pampublikong pangalan, hindi ang mga panloob, at ang app na nabibigo ay mukhang gumagamit ng maling DNS server, dahil ganoon nga. Karaniwang mas maliit ang pag-aayos kaysa sa ipinahihiwatig ng diagnosis.

Hakbang 1: Subukan mula sa app, hindi mula sa host

Patakbuhin ang paghahanap sa loob ng container na may problema, hindi sa host at hindi sa browser. docker exec app-container getent hosts db.internal sinasagot ang tanging tanong na mahalaga: ano ang ibinabalik ng resolver ng prosesong ito.

Kung nareresolba ng host ang pangalan at hindi ng container, natagpuan mo ang depekto. Ang lahat pagkatapos nito ay pagpili ng sinusuportahang paraan upang ayusin ito.

Hakbang 2: Basahin ang sinusuportahang modelo ng runtime

Ang dokumentasyon ng network ng Docker nagtatala ng mga paghihigpit sa mga flag ng DNS para sa mga container na nagbabahagi ng network mode ng ibang container. Sa Compose network_mode: service:vpn itinatali ang app sa namespace ng VPN container, at bawat serbisyo dns ang mga setting ay hindi kumikilos tulad ng sa ordinaryong serbisyo. Ang resolution na nakukuha mo ay yaong mayroon ang pinagsasaluhang namespace.

Ang mga bridge network na tinukoy ng user ay gumagamit din ng embedded DNS ng Docker nang iba kaysa sa default na bridge. Kaya naman ang dns sugnay na kinopya mula sa gumaganang halimbawa ng bridge ay maaaring walang gawin sa pinagsasaluhang stack. Suriin ang kaayusan bago kopyahin ang sugnay.

Ang loopback address ay laging tumutukoy sa kaugnay na konteksto ng network. Sa loob ng pinagsasaluhang namespace, 127.0.0.1 hindi ito ang resolver ng host.

Hakbang 3: Sundan ang query hanggang sa tatanggap nito

Basahin ang configuration ng resolver ng app, pagkatapos ang anumang encrypted DNS na partikular sa app na dala nito, dahil ang app na nagpapatakbo ng sarili nitong resolver ay binabalewala ang file na in-edit mo. Pagkatapos suriin kung naaabot ang napiling resolver sa ilalim ng mga ruta at patakaran ng firewall ng VPN. Walang silbi ang address ng resolver sa kabilang panig ng tunnel kung walang ruta ang namespace patungo roon. Kumpirmahin ang tatanggap bago mag-edit ng anumang file.

Hindi masasabi ng pahina ng pagsusuri ng IP sa browser kung saan nagpunta ang mga query ng pangalan. Sinasabi nito kung saan nagpunta ang isang koneksyon ng HTTP.

Hakbang 4: Ayusin ang dalawang klase ng pagkabigo nang magkaiba

Kung nabibigo ang mga pangalan ng serbisyo habang gumagana ang mga pampublikong pangalan, ang problema ay ang pagtuklas ng serbisyo sa loob ng network ng container, hindi ang listahan ng mga pampublikong resolver. Ang pagbabago ng bawat pampublikong DNS address ay hindi gagawa ng mga record na hindi kailanman hiniling sa mekanismo ng pagtuklas ng network.

Kung parehong nabibigo ang dalawang klase, magsimula sa pag-abot sa resolver. Kung isa lang ang nabibigo, magsimula sa mekanismo ng pagtuklas. Magkaiba ang may-ari ng dalawa, kaya hindi kailanman sinasaklaw ng isang pag-aayos ang pareho.

Hakbang 5: Subukan muli pagkatapos muling likhain

Baguhin ang configuration sa pamamagitan ng sinusuportahang mekanismo ng runtime, pagkatapos muling likhain ang mga container sa halip na mag-edit ng mga file sa loob ng tumatakbo. Subukan ang bagong pribadong pangalan, bagong pampublikong pangalan at ang kahilingan ng app na sumusunod sa paghahanap. /etc/resolv.conf sa loob ng container ay nawawala sa muling paglikha at kukumbinsihin ka na gumana ang pag-aayos gayong hindi naman.

Itala ang may-ari ng resolver at ang inaasahang namespace sa tabi ng depinisyon ng pinagsasaluhang network. Kakailanganin ng susunod na tao ang dalawa.