ip netns exec at DNS: bakit nabigo ang mga pangalan sa loob ng namespace

Ang isang utos ay umaabot sa 10.8.0.5 sa loob ng namespace ng VPN nang walang anumang reklamo, at ang parehong utos ay nabigo sa sandaling gumamit ito ng hostname. May sariling mga interface, ruta at socket ang namespace; wala itong sariling file ng resolver. Maliban kung may maglagay ng isa roon, binabasa ng proseso sa loob ang /etc/resolv.conf ng host at nagtatanong sa isang server na maaaring hindi maabot mula sa stack ng network na iyon.

Ito ay problema sa pagpili ng file at hindi problema sa routing, at iyon mismo ang dahilan kung bakit gumagana pa rin ang numeric na destinasyon.

Suriin ang view ng resolver na aktwal na natatanggap ng proseso

Huwag ipagpalagay na ang shell na ginamit mo ay katumbas ng prosesong ini-debug mo. Ang isang graphical na application, isang systemd unit at isang container ay maaaring masing pumasok sa ibang konteksto ng mount o ng network. Patakbuhin ang lookup sa pamamagitan ng parehong landas ng paglulunsad, at i-print ang file ng resolver mula sa loob.

Para sa namespace na ginawa gamit ang ip netns add, ang read-only na pagsusuri ay maikli:

ip netns exec vpn cat /etc/resolv.conf

Pansinin kung ang resulta ay nagpapangalan ng maabot na address, isang stub ng loopback, o isang symbolic link na tumuturo sa isang lugar na may ibang maabot.

Ano ang aktwal na ini-mount ng exec helper

Dinodokumento ng tool na ip-netns ang configuration bawat namespace sa ilalim ng /etc/netns/NAME/. Kapag naglunsad ito ng proseso, gumagawa ang helper ng mount namespace at ini-mount ang mga file na iyon sa ibabaw ng kanilang karaniwang mga landas, kaya nakikita ng proseso ang kopyang partikular sa namespace. Iyon ay isang kaginhawahan ng partikular na launcher na ito. Ang pagpasok sa isang network namespace sa ibang landas, tulad ng unshare o isang container runtime, ay hindi awtomatikong nagpaparami niyon.

Ang loopback resolver ang bitag dito: ang 127.0.0.53 ay nangangahulugan ng sariling loopback ng namespace, hindi ang stub ng host. Ang isang stub na nakikinig lamang sa namespace ng host ay hindi nagiging serbisyo sa bago.

Pumili ng resolver na maaabot ng namespace

Anuman ang server na pangalanan ng file, kailangan pa rin nito ng ruta mula sa namespace na iyon. Ang isang pampublikong resolver ay maaaring sumagot sa mga pampublikong pangalan at nabigo pa rin para sa isang panloob na zone, dahil ang pribadong serbisyo ay maaabot lamang sa pamamagitan ng tunnel. Suriin ang ruta kasabay ng address, hindi pagkatapos na nabigo na ang lookup.

Ang mga application na may sariling resolver, tulad ng isang gumagamit ng DNS over HTTPS, ay maaaring ganap na huwag pansinin ang file. Kung ang tool ay may sariling setting ng DNS, hindi ito maaapektuhan ng pagbabago ng resolv.conf, at ang namespace ay hindi kailanman naging problema.

Isulat ang file sa tamang lugar

Gumawa ng file bawat namespace sa ilalim ng /etc/netns/NAME/resolv.conf at hayaang ipakita ito ng launcher. Panatilihin itong minimal: isa o dalawang maabot na server at ang mga domain ng paghahanap na kailangan ng gawain. Huwag i-edit ang nabuong file ng resolver ng host upang ayusin ang isang view na inilaan para sa isang grupo ng mga proseso, dahil binabago niyon ang bawat application sa makina. Kung gumagamit ang host ng manager ng resolver, i-configure ang landas ng namespace sa pamamagitan ng manager na iyon sa halip na makipaglaban dito.

Itala ang nilalaman ng file sa runbook. Kung hindi, susubukan ng susunod na tao ang resolver ng host, makikita ang isang sagot na gumagana at maghihinuha na maayos ang namespace.

Subukan muli ang buong landas

Subukan sa loob ng namespace gamit ang numeric na address, panloob na pangalan at pampublikong pangalan. Ang pagkakasunod-sunod na iyon ay naghihiwalay ng maabot mula sa resolusyon at naghihiwalay ng mga panloob na zone mula sa mga pampubliko. Pagkatapos ay muling gawin ang namespace at ulitin, dahil ang isang file na umiiral lamang sa tumatakbong instance ay nawawala kasama nito.

Kumpirmahin na ang proseso, hindi ang shell, ang tumatanggap ng file. Ang isang lookup na gumagana mula sa isang interactive na shell at nabigo mula sa isang serbisyo ay isang natuklasan tungkol sa konteksto ng mount, at sulit itong isulat bago ang susunod na insidente sa halip na muling tuklasin ito mula sa simula.