ip netns exec en DNS: waarom namen binnen de namespace mislukken

Een commando bereikt 10.8.0.5 binnen de VPN-namespace zonder enige klacht, en hetzelfde commando faalt op het moment dat het een hostnaam gebruikt. De namespace heeft zijn eigen interfaces, routes en sockets; hij heeft geen eigen resolverbestand. Tenzij iets er een daar neerzet, leest het proces binnenin de /etc/resolv.conf van de host en vraagt het een server die misschien niet bereikbaar is vanaf die netwerkstack.

Dat is een bestandsselectieprobleem en geen routingprobleem, en precies daarom werkt de numerieke bestemming nog steeds.

Controleer de resolverweergave die het proces daadwerkelijk krijgt

Ga er niet van uit dat de shell die je gebruikte gelijk is aan het proces dat je debugt. Een grafische toepassing, een systemd-unit en een container kunnen elk een andere mount- of netwerkcontext binnengaan. Voer de opzoeking via hetzelfde startpad uit en druk het resolverbestand van binnenuit af.

Voor een namespace die met ip netns add is gemaakt, is de alleen-lezen-controle kort:

ip netns exec vpn cat /etc/resolv.conf

Let op of het resultaat een bereikbaar adres, een loopback-stub of een symbolische koppeling noemt die naar een plek met andere bereikbaarheid wijst.

Wat de exec-helper werkelijk mount

Het hulpprogramma ip-netns documenteert configuratie per namespace onder /etc/netns/NAME/. Wanneer het een proces start, maakt de helper een mount-namespace en bind-mount die bestanden over hun gebruikelijke paden, zodat het proces de namespacespecifieke kopie ziet. Dat is een gemak van precies deze starter. Een netwerknamespace via een andere route binnengaan, bijvoorbeeld via unshare of een container-runtime, reproduceert dat niet automatisch.

De loopback-resolver is hier de val: 127.0.0.53 betekent de eigen loopback van de namespace, niet de stub van de host. Een stub die alleen in de hostnamespace luistert, wordt geen dienst in de nieuwe.

Kies een resolver die de namespace kan bereiken

Welke server het bestand ook noemt, die heeft nog steeds een route vanuit die namespace nodig. Een publieke resolver kan publieke namen beantwoorden en toch falen voor een interne zone, omdat de private dienst alleen via de tunnel bereikbaar is. Controleer de route tegelijk met het adres, niet nadat de opzoeking al is mislukt.

Toepassingen met hun eigen resolver, zoals een die DNS over HTTPS gebruikt, kunnen het bestand volledig negeren. Als het hulpprogramma een eigen DNS-instelling heeft, verandert het wijzigen van resolv.conf daar niets aan, en de namespace was nooit het probleem.

Schrijf het bestand op de juiste plek

Maak het bestand per namespace onder /etc/netns/NAME/resolv.conf aan en laat de starter het presenteren. Houd het minimaal: een of twee bereikbare servers en de zoekdomeinen die de taak nodig heeft. Bewerk niet het gegenereerde resolverbestand van de host om een weergave voor één groep processen te repareren, want dat verandert elke toepassing op de machine. Als de host een resolverbeheerder gebruikt, configureer dan het namespacepad via die beheerder in plaats van ertegen te vechten.

Leg de inhoud van het bestand vast in de runbook. Anders test de volgende persoon de resolver van de host, ziet een werkend antwoord en concludeert dat de namespace in orde is.

Test het hele pad opnieuw

Test binnen de namespace met een numeriek adres, een interne naam en een publieke naam. Die volgorde scheidt bereikbaarheid van resolutie en scheidt interne zones van publieke. Maak daarna de namespace opnieuw aan en herhaal, want een bestand dat alleen in een draaiende instantie bestaat, verdwijnt ermee.

Bevestig dat het proces, niet de shell, het bestand ontvangt. Een opzoeking die vanuit een interactieve shell werkt en vanuit een dienst faalt, is een bevinding over de mountcontext, en het is de moeite waard die vóór het volgende incident op te schrijven in plaats van hem vanaf nul opnieuw te ontdekken.