ip netns exec og DNS: kvifor namn feilar inne i namnerommet

Ein kommando når 10.8.0.5 inne i VPN-namnerommet utan klager, og den same kommandoen feilar i det augneblinken han brukar eit vertsnamn. Namnerommet har sine eigne grensesnitt, ruter og sokkar; det har ikkje si eiga oppløysarfil. Med mindre noko legg ei slik fil der, les prosessen inni verten si /etc/resolv.conf og spør ein tenar som kanskje ikkje er tilgjengeleg frå den nettverksstakken.

Dette er eit filvalproblem og ikkje eit ruteproblem, og det er nettopp difor den numeriske destinasjonen framleis verkar.

Kontroller oppløysarbiletet prosessen faktisk får

Ikkje gå ut frå at skalet du brukte svarar til prosessen du feilsøkjer. Ein grafisk applikasjon, ei systemd-eining og ein container kan kvar gå inn i ein annan monterings- eller nettverkskontekst. Køyr oppslaget gjennom same startveg, og skriv ut oppløysarfilen frå innsida.

For eit namnerom laga med ip netns add er lese-kontrollen kort:

ip netns exec vpn cat /etc/resolv.conf

Legg merke til om resultatet nemner ei tilgjengeleg adresse, ein loopback-stub eller ei symbolsk lenkje som peikar til ein stad med annan tilgjenge.

Kva exec-hjelparen eigentleg monterer

Verktøyet ip-netns dokumenterer konfigurasjon per namnerom under /etc/netns/NAME/. Når det startar ein prosess, lagar hjelparen eit monteringsnamnerom og bind-monterer desse filene over dei vanlege stiane sine, slik at prosessen ser den namneromsspesifikke kopien. Det er ei lettvintheit ved nettopp denne startaren. Å gå inn i eit nettverksnamnerom via ein annan veg, til dømes unshare eller ein container-runtime, gjer ikkje det same automatisk.

Ein loopback-oppløysar er fella her: 127.0.0.53 tyder namnerommet sin eigen loopback, ikkje verten sin stub. Ein stub som berre lyttar i verten sitt namnerom, vert ikkje ei teneste i det nye.

Vel ein oppløysar som namnerommet kan nå

Kva tenar fila enn nemner, treng han framleis ei rute frå det namnerommet. Ein offentleg oppløysar kan svare på offentlege namn og likevel feile for ei intern sone, fordi den private tenesta berre er tilgjengeleg gjennom tunnelen. Kontroller ruta samstundes med adressa, ikkje etter at oppslaget alt har feila.

Applikasjonar med eigen oppløysar, til dømes ein som brukar DNS over HTTPS, kan heilt ignorere fila. Viss verktøyet har si eiga DNS-innstilling, vil endring av resolv.conf ikkje påverke det, og namnerommet var aldri problemet.

Skriv fila på rett stad

Lag fila per namnerom under /etc/netns/NAME/resolv.conf og la startaren presentere ho. Hald ho minimal: ein eller to tilgjengelege tenarar og søkjedomena oppgåva treng. Ikkje rediger den genererte oppløysarfilen til verten for å rette eit bilete meint for éi gruppe prosessar, for det endrar kvar applikasjon på maskina. Viss verten brukar ein oppløysarhandsamar, konfigurer stien til namnerommet gjennom den handsamaren i staden for å kjempe mot han.

Noter innhaldet i fila i runbooken. Elles testar neste person oppløysaren til verten, ser eit svar som verkar og konkluderer med at namnerommet er i orden.

Test heile stien på nytt

Test inne i namnerommet med ei numerisk adresse, eit internt namn og eit offentleg namn. Den rekkjefølgja skil tilgjenge frå oppslag og skil interne soner frå offentlege. Lag deretter namnerommet på nytt og gjer det om att, for ei fil som berre finst i ein køyrande instans, forsvinn med han.

Stadfest at det er prosessen, ikkje skalet, som får fila. Eit oppslag som verkar frå eit interaktivt skall og feilar frå ei teneste, er eit funn om monteringskonteksten, og det er verdt å skrive ned før neste hending i staden for å oppdage det på nytt frå botnen.