ip netns exec og DNS: hvorfor navne fejler inde i navnerummet

En kommando når 10.8.0.5 inde i VPN-navnerummet uden klager, og den samme kommando fejler i det øjeblik, den bruger et værtsnavn. Navnerummet har sine egne grænseflader, ruter og sockets; det har ikke sin egen resolverfil. Medmindre noget lægger en sådan fil der, læser processen indeni værtens /etc/resolv.conf og spørger en server, som muligvis ikke kan nås fra den netværksstak.

Det er et filvalgsproblem og ikke et ruteproblem, og det er netop derfor den numeriske destination stadig virker.

Kontroller det resolverbillede, processen faktisk får

Antag ikke, at den shell, du brugte, svarer til den proces, du fejlretter. En grafisk applikation, en systemd-unit og en container kan hver især gå ind i en anden monterings- eller netværkskontekst. Kør opslaget gennem samme startvej, og udskriv resolverfilen indefra.

For et navnerum oprettet med ip netns add er læse-kun-kontrollen kort:

ip netns exec vpn cat /etc/resolv.conf

Bemærk, om resultatet angiver en nåbar adresse, en loopback-stub eller et symbolsk link, der peger et sted hen med en anden nåbarhed.

Hvad exec-hjælperen egentlig monterer

Værktøjet ip-netns dokumenterer konfigurationen for hvert navnerum under /etc/netns/NAME/. Når det starter en proces, opretter hjælperen et monteringsnavnerum og bind-monterer disse filer oven på deres sædvanlige stier, så processen ser den navnerumsspecifikke kopi. Det er en bekvemmelighed ved netop denne starter. At gå ind i et netværksnavnerum ad en anden vej, for eksempel via unshare eller en container-runtime, genskaber det ikke automatisk.

En loopback-resolver er fælden her: 127.0.0.53 betyder navnerummets egen loopback, ikke værtens stub. En stub, der kun lytter i værtens navnerum, bliver ikke en tjeneste i det nye.

Vælg en resolver, som navnerummet kan nå

Hvilken server filen end angiver, kræver den stadig en rute fra det navnerum. En offentlig resolver kan svare på offentlige navne og alligevel fejle for en intern zone, fordi den private tjeneste kun kan nås gennem tunnelen. Kontroller ruten samtidig med adressen, ikke efter opslaget allerede er fejlet.

Applikationer med deres egen resolver, for eksempel en der bruger DNS over HTTPS, kan ignorere filen helt. Hvis værktøjet har sin egen DNS-indstilling, vil ændring af resolv.conf ikke påvirke det, og navnerummet var aldrig problemet.

Skriv filen det rigtige sted

Opret filen for hvert navnerum under /etc/netns/NAME/resolv.conf og lad starteren præsentere den. Hold den minimal: en eller to nåbare servere og de søgedomæner, opgaven har brug for. Rediger ikke værtens genererede resolverfil for at rette et billede beregnet til én gruppe processer, for det ændrer enhver applikation på maskinen. Hvis værten bruger en resolvermanager, skal du konfigurere navnerummets sti gennem den manager i stedet for at kæmpe imod den.

Noter filens indhold i runbooken. Ellers tester den næste person værtens resolver, ser et svar, der virker, og konkluderer, at navnerummet er i orden.

Test hele stien igen

Test inde i navnerummet med en numerisk adresse, et internt navn og et offentligt navn. Den rækkefølge adskiller nåbarhed fra opløsning og adskiller interne zoner fra offentlige. Genopret derefter navnerummet og gentag, for en fil, der kun findes i en kørende instans, forsvinder med den.

Bekræft, at det er processen og ikke shellen, der modtager filen. Et opslag, der virker fra en interaktiv shell og fejler fra en tjeneste, er et fund om monteringskontekst, og det er værd at skrive ned før næste hændelse i stedet for at genopdage det fra bunden.