ip netns exec a DNS: proč názvy uvnitř jmenného prostoru selhávají

Příkaz se dostane na 10.8.0.5 uvnitř jmenného prostoru VPN bez jakékoli stížnosti a tentýž příkaz selže ve chvíli, kdy použije název hostitele. Jmenný prostor má vlastní rozhraní, trasy a sockety; nemá vlastní soubor překladače. Pokud tam něco takový soubor neumístí, proces uvnitř čte /etc/resolv.conf hostitele a ptá se serveru, který nemusí být z tohoto síťového zásobníku dostupný.

To je problém volby souboru, nikoli problém směrování, a právě proto číselný cíl stále funguje.

Zkontrolujte pohled překladače, který proces skutečně dostane

Nepředpokládejte, že shell, který jste použili, je ekvivalentní procesu, který ladíte. Grafická aplikace, jednotka systemd a kontejner mohou každý vstoupit do jiného kontextu připojení nebo sítě. Spusťte dotaz stejnou cestou spuštění a vypište soubor překladače z jejího nitra.

Pro jmenný prostor vytvořený pomocí ip netns add je kontrola pouze pro čtení krátká:

ip netns exec vpn cat /etc/resolv.conf

Všimněte si, zda výsledek uvádí dostupnou adresu, zástupný bod loopback, nebo symbolický odkaz, který míří někam s odlišnou dostupností.

Co pomocník exec skutečně připojuje

Nástroj ip-netns dokumentuje konfiguraci pro jednotlivé jmenné prostory pod /etc/netns/NAME/. Když spustí proces, pomocník vytvoří jmenný prostor připojení a připojí tyto soubory přes jejich obvyklé cesty, takže proces vidí kopii specifickou pro jmenný prostor. To je výhoda tohoto konkrétního spouštěče. Vstup do síťového jmenného prostoru jinou cestou, například přes unshare nebo kontejnerový runtime, to automaticky nezopakuje.

Překladač na loopback je tady past: 127.0.0.53 znamená vlastní loopback jmenného prostoru, ne zástupný bod hostitele. Zástupný bod, který naslouchá jen v jmenném prostoru hostitele, se v novém nestane službou.

Vyberte překladač, na který se jmenný prostor dostane

Ať soubor uvádí jakýkoli server, stále potřebuje trasu z tohoto jmenného prostoru. Veřejný překladač může odpovídat na veřejné názvy a přesto selhat pro interní zónu, protože soukromá služba je dostupná jen tunelem. Kontrolujte trasu současně s adresou, ne až poté, co dotaz už selhal.

Aplikace s vlastním překladačem, například ta, která používá DNS over HTTPS, mohou soubor úplně ignorovat. Pokud má nástroj vlastní nastavení DNS, změna resolv.conf jej neovlivní a jmenný prostor nikdy nebyl problém.

Zapište soubor na správné místo

Vytvořte soubor pro jmenný prostor pod /etc/netns/NAME/resolv.conf a nechte spouštěč, ať jej předloží. Držte ho minimální: jeden nebo dva dostupné servery a vyhledávací domény, které úloha potřebuje. Neupravujte generovaný soubor překladače hostitele, abyste opravili pohled určený jedné skupině procesů, protože tím změníte každou aplikaci na stroji. Pokud hostitel používá správce překladače, nakonfigurujte cestu jmenného prostoru přes tohoto správce, místo abyste s ním bojovali.

Zaznamenejte obsah souboru do runbooku. Jinak příští člověk otestuje překladač hostitele, uvidí fungující odpověď a usoudí, že jmenný prostor je v pořádku.

Otestujte znovu celou cestu

Testujte uvnitř jmenného prostoru s číselnou adresou, interním názvem a veřejným názvem. Tato posloupnost odděluje dostupnost od překladu a odděluje interní zóny od veřejných. Potom jmenný prostor znovu vytvořte a opakujte, protože soubor, který existuje jen v běžící instanci, s ní zmizí.

Ověřte, že soubor dostává proces, ne shell. Dotaz, který funguje z interaktivního shellu a selhává ze služby, je zjištění o kontextu připojení a stojí za to si ho zapsat před dalším incidentem, místo abyste ho znovu objevovali od nuly.