ip netns exec og DNS: hvorfor navn feiler inne i navnerommet

En kommando når 10.8.0.5 inne i VPN-navnerommet uten klager, og den samme kommandoen feiler i det øyeblikket den bruker et vertsnavn. Navnerommet har sine egne grensesnitt, ruter og sockets; det har ikke sin egen resolverfil. Med mindre noe legger en slik fil der, leser prosessen inni vertens /etc/resolv.conf og spør en server som kanskje ikke er tilgjengelig fra den nettverksstakken.

Dette er et filvalgsproblem og ikke et ruteproblem, og det er nettopp derfor den numeriske destinasjonen fortsatt virker.

Kontroller resolverbildet prosessen faktisk får

Ikke anta at skallet du brukte tilsvarer prosessen du feilsøker. En grafisk applikasjon, en systemd-enhet og en container kan hver gå inn i en annen monterings- eller nettverkskontekst. Kjør oppslaget gjennom samme startvei, og skriv ut resolverfilen innenfra.

For et navnerom laget med ip netns add er lese-kun-kontrollen kort:

ip netns exec vpn cat /etc/resolv.conf

Legg merke til om resultatet nevner en tilgjengelig adresse, en loopback-stub eller en symbolsk lenke som peker et sted med annen tilgjengelighet.

Hva exec-hjelperen egentlig monterer

Verktøyet ip-netns dokumenterer konfigurasjon per navnerom under /etc/netns/NAME/. Når det starter en prosess, lager hjelperen et monteringsnavnerom og bind-monterer disse filene over deres vanlige stier, slik at prosessen ser den navneromsspesifikke kopien. Det er en bekvemmelighet ved nettopp denne starteren. Å gå inn i et nettverksnavnerom via en annen vei, for eksempel unshare eller en container-runtime, gjenskaper det ikke automatisk.

En loopback-resolver er fellen her: 127.0.0.53 betyr navnerommets egen loopback, ikke vertens stub. En stub som bare lytter i vertens navnerom, blir ikke en tjeneste i det nye.

Velg en resolver som navnerommet kan nå

Hvilken server filen enn nevner, trenger den fortsatt en rute fra det navnerommet. En offentlig resolver kan svare på offentlige navn og likevel feile for en intern sone, fordi den private tjenesten bare er tilgjengelig gjennom tunnelen. Kontroller ruten samtidig med adressen, ikke etter at oppslaget allerede har feilet.

Applikasjoner med egen resolver, for eksempel en som bruker DNS over HTTPS, kan ignorere filen helt. Hvis verktøyet har sin egen DNS-innstilling, vil endring av resolv.conf ikke påvirke det, og navnerommet var aldri problemet.

Skriv filen på riktig sted

Lag filen per navnerom under /etc/netns/NAME/resolv.conf og la starteren presentere den. Hold den minimal: én eller to tilgjengelige servere og søkedomenene oppgaven trenger. Ikke rediger vertens genererte resolverfil for å rette et bilde ment for én gruppe prosesser, for det endrer hver applikasjon på maskinen. Hvis verten bruker en resolverbehandler, konfigurer navnerommets sti gjennom den behandleren i stedet for å kjempe mot den.

Noter filinnholdet i runbooken. Ellers tester neste person vertens resolver, ser et svar som virker og konkluderer med at navnerommet er i orden.

Test hele stien på nytt

Test inne i navnerommet med en numerisk adresse, et internt navn og et offentlig navn. Den rekkefølgen skiller tilgjengelighet fra oppslag og skiller interne soner fra offentlige. Lag deretter navnerommet på nytt og gjenta, for en fil som bare finnes i en kjørende instans, forsvinner med den.

Bekreft at det er prosessen, ikke skallet, som mottar filen. Et oppslag som virker fra et interaktivt skall og feiler fra en tjeneste, er et funn om monteringskonteksten, og det er verdt å skrive ned før neste hendelse i stedet for å gjenoppdage det fra bunnen.