ip netns exec a DNS: prečo názvy zlyhávajú vo vnútri menného priestoru

Príkaz sa dostane na 10.8.0.5 vo vnútri menného priestoru VPN bez akýchkoľvek sťažností a ten istý príkaz zlyhá vo chvíli, keď použije názov hostiteľa. Menný priestor má vlastné rozhrania, trasy a sockety; nemá vlastný súbor prekladača. Ak tam niečo taký súbor neumiestni, proces vnútri číta /etc/resolv.conf hostiteľa a pýta sa servera, ktorý nemusí byť dostupný z tohto sieťového zásobníka.

Je to problém výberu súboru, nie problém smerovania, a práve preto číselný cieľ stále funguje.

Skontrolujte pohľad prekladača, ktorý proces skutočne dostane

Nepredpokladajte, že shell, ktorý ste použili, je ekvivalentný procesu, ktorý ladíte. Grafická aplikácia, jednotka systemd a kontajner môžu každý vstúpiť do iného kontextu pripojenia alebo siete. Spustite vyhľadávanie tou istou cestou spustenia a vypíšte súbor prekladača zvnútra.

Pre menný priestor vytvorený pomocou ip netns add je kontrola iba na čítanie krátka:

ip netns exec vpn cat /etc/resolv.conf

Všimnite si, či výsledok uvádza dostupnú adresu, zástupný bod loopback alebo symbolický odkaz, ktorý ukazuje na miesto s inou dostupnosťou.

Čo pomocník exec skutočne pripája

Nástroj ip-netns dokumentuje konfiguráciu pre jednotlivé menné priestory pod /etc/netns/NAME/. Keď spustí proces, pomocník vytvorí menný priestor pripojenia a pripojí tieto súbory nad ich obvyklé cesty, takže proces vidí kópiu špecifickú pre menný priestor. To je výhoda práve tohto spúšťača. Vstup do sieťového menného priestoru inou cestou, napríklad cez unshare alebo runtime kontajnerov, to automaticky nezopakuje.

Prekladač na loopback je tu pasca: 127.0.0.53 znamená vlastný loopback menného priestoru, nie zástupný bod hostiteľa. Zástupný bod, ktorý počúva len v mennom priestore hostiteľa, sa v novom nestane službou.

Vyberte prekladač, ku ktorému sa menný priestor dostane

Nech súbor uvádza akýkoľvek server, stále potrebuje trasu z tohto menného priestoru. Verejný prekladač môže odpovedať na verejné názvy a napriek tomu zlyhať pre internú zónu, pretože súkromná služba je dostupná len cez tunel. Kontrolujte trasu súčasne s adresou, nie až potom, čo vyhľadávanie už zlyhalo.

Aplikácie s vlastným prekladačom, napríklad tá, ktorá používa DNS over HTTPS, môžu súbor úplne ignorovať. Ak má nástroj vlastné nastavenie DNS, zmena resolv.conf ho neovplyvní a menný priestor nikdy nebol problém.

Zapíšte súbor na správne miesto

Vytvorte súbor pre menný priestor pod /etc/netns/NAME/resolv.conf a nechajte spúšťač, aby ho predložil. Držte ho minimálny: jeden alebo dva dostupné servery a vyhľadávacie domény, ktoré úloha potrebuje. Neupravujte vygenerovaný súbor prekladača hostiteľa, aby ste opravili pohľad určený jednej skupine procesov, pretože to zmení každú aplikáciu na stroji. Ak hostiteľ používa správcu prekladača, nakonfigurujte cestu menného priestoru cez tohto správcu, namiesto toho, aby ste s ním bojovali.

Zaznamenajte obsah súboru do runbooku. Inak nasledujúci človek otestuje prekladač hostiteľa, uvidí fungujúcu odpoveď a usúdi, že menný priestor je v poriadku.

Otestujte znova celú cestu

Testujte vo vnútri menného priestoru s číselnou adresou, interným názvom a verejným názvom. Táto postupnosť oddeľuje dostupnosť od prekladu a oddeľuje interné zóny od verejných. Potom menný priestor znova vytvorte a zopakujte, pretože súbor, ktorý existuje len v bežiacej inštancii, s ňou zmizne.

Overte, že súbor dostáva proces, nie shell. Vyhľadávanie, ktoré funguje z interaktívneho shellu a zlyháva zo služby, je zistenie o kontexte pripojenia a stojí za to si ho zapísať pred ďalším incidentom, namiesto toho, aby ste ho znova objavovali od nuly.