ip netns exec och DNS: varför namn misslyckas inuti namnrymden

Ett kommando når 10.8.0.5 inuti VPN-namnrymden utan klagomål, och samma kommando misslyckas i samma stund som det använder ett värdnamn. Namnrymden har sina egna gränssnitt, rutter och sockets; den har inte sin egen resolverfil. Om inte något lägger en sådan fil där läser processen inuti värdens /etc/resolv.conf och frågar en server som kanske inte går att nå från den nätverksstacken.

Det är ett filvalsproblem och inte ett routingproblem, och det är just därför den numeriska destinationen fortfarande fungerar.

Kontrollera resolvervyn som processen faktiskt får

Anta inte att skalet du använde motsvarar processen du felsöker. Ett grafiskt program, en systemd-enhet och en container kan var och en gå in i en annan monterings- eller nätverkskontext. Kör uppslaget via samma startväg och skriv ut resolverfilen inifrån.

För en namnrymd som skapats med ip netns add är skrivskyddskontrollen kort:

ip netns exec vpn cat /etc/resolv.conf

Notera om resultatet anger en nåbar adress, en loopback-stub eller en symbolisk länk som pekar på en plats med annan nåbarhet.

Vad exec-hjälparen egentligen monterar

Verktyget ip-netns dokumenterar konfiguration per namnrymd under /etc/netns/NAME/. När det startar en process skapar hjälparen en monteringsnamnrymd och bind-monterar dessa filer över deras vanliga sökvägar, så att processen ser den namnrymdsspecifika kopian. Det är en bekvämlighet hos just den här startaren. Att gå in i en nätverksnamnrymd via en annan väg, till exempel unshare eller en container-runtime, återskapar inte det automatiskt.

Loopback-resolvern är fällan här: 127.0.0.53 betyder namnrymdens egen loopback, inte värdens stub. En stub som bara lyssnar i värdens namnrymd blir inte en tjänst i den nya.

Välj en resolver som namnrymden kan nå

Vilken server filen än anger, behöver den fortfarande en rutt från den namnrymden. En offentlig resolver kan svara på offentliga namn och ändå misslyckas för en intern zon, eftersom den privata tjänsten bara går att nå via tunneln. Kontrollera rutten samtidigt som adressen, inte efter att uppslaget redan har misslyckats.

Program med egen resolver, till exempel ett som använder DNS over HTTPS, kan ignorera filen helt. Om verktyget har en egen DNS-inställning påverkar ändringen av resolv.conf det inte, och namnrymden var aldrig problemet.

Skriv filen på rätt ställe

Skapa filen per namnrymd under /etc/netns/NAME/resolv.conf och låt startaren presentera den. Håll den minimal: en eller två nåbara servrar och de sökdomäner som uppgiften behöver. Redigera inte värdens genererade resolverfil för att fixa en vy avsedd för en grupp processer, för det ändrar varje program på maskinen. Om värden använder en resolverhanterare konfigurerar du namnrymdens sökväg via den hanteraren i stället för att kämpa mot den.

Skriv ned filens innehåll i runbooken. Annars testar nästa person värdens resolver, ser ett svar som fungerar och drar slutsatsen att namnrymden är i ordning.

Testa hela vägen igen

Testa inne i namnrymden med en numerisk adress, ett internt namn och ett offentligt namn. Den ordningen skiljer nåbarhet från uppslagning och skiljer interna zoner från offentliga. Återskapa sedan namnrymden och upprepa, för en fil som bara finns i en körande instans försvinner med den.

Bekräfta att det är processen, inte skalet, som tar emot filen. Ett uppslag som fungerar från ett interaktivt skal och misslyckas från en tjänst är ett fynd om monteringskontexten, och det är värt att skriva ned före nästa incident i stället för att upptäcka det på nytt från början.