ip netns exec dhe DNS: pse dështojnë emrat brenda hapësirës së emrave

Një komandë arrin në 10.8.0.5 brenda hapësirës së emrave të VPN-së pa asnjë ankesë, dhe e njëjta komandë dështon në momentin që përdor një emër hosti. Hapësira e emrave ka ndërfaqet, rrugët dhe socket-et e veta; nuk ka skedarin e vet të zgjidhësit. Nëse diçka nuk vendos një atje, procesi brenda lexon /etc/resolv.conf e hostit dhe pyet një server që mund të mos jetë i arritshëm nga ai stivë rrjeti.

Ky është problem i zgjedhjes së skedarit dhe jo problem rrugëtimi, dhe pikërisht për këtë destinacioni numerik ende funksionon.

Kontrolloni pamjen e zgjidhësit që procesi merr në të vërtetë

Mos supozoni se shell-i që përdorët është i barabartë me procesin që po korrigjoni. Një aplikacion grafik, një njësi systemd dhe një kontejner mund secili të hyjë në një kontekst tjetër montimi ose rrjeti. Ekzekutoni kërkimin përmes të njëjtës rrugë nisjeje dhe shtypni skedarin e zgjidhësit nga brenda.

Për një hapësirë emrash të krijuar me ip netns add, kontrolli vetëm-lexim është i shkurtër:

ip netns exec vpn cat /etc/resolv.conf

Vini re nëse rezultati emërton një adresë të arritshme, një stub loopback ose një lidhje simbolike që tregon drejt një vendi me arritshmëri tjetër.

Çfarë monton në të vërtetë ndihmësi exec

Mjeti ip-netns dokumenton konfigurimin për çdo hapësirë emrash nën /etc/netns/NAME/. Kur nis një proces, ndihmësi krijon një hapësirë emrash montimi dhe monton ato skedarë mbi rrugët e tyre të zakonshme, kështu që procesi sheh kopjen specifike të hapësirës së emrave. Kjo është një lehtësi e këtij nisësi të caktuar. Hyrja në një hapësirë emrash rrjeti nga një rrugë tjetër, si unshare ose një runtime kontejnerësh, nuk e riprodhon atë automatikisht.

Kurthi këtu është zgjidhësi i loopback-ut: 127.0.0.53 nënkupton loopback-un e vetë hapësirës së emrave, jo stub-in e hostit. Një stub që dëgjon vetëm në hapësirën e emrave të hostit nuk bëhet shërbim në atë të re.

Zgjidhni një zgjidhës që hapësira e emrave mund ta arrijë

Cilin do server që skedari emërton, ai ende ka nevojë për një rrugë nga ajo hapësirë emrash. Një zgjidhës publik mund t’u përgjigjet emrave publikë dhe gjithsesi të dështojë për një zonë të brendshme, sepse shërbimi privat është i arritshëm vetëm përmes tunelit. Kontrolloni rrugën në të njëjtën kohë me adresën, jo pasi kërkimi ka dështuar tashmë.

Aplikacionet me zgjidhës të vetin, si ai që përdor DNS mbi HTTPS, mund ta injorojnë plotësisht skedarin. Nëse mjeti ka cilësimin e vet të DNS-së, ndryshimi i resolv.conf nuk do ta prekë atë, dhe hapësira e emrave nuk ishte kurrë problemi.

Shkruajeni skedarin në vendin e duhur

Krijoni skedarin për hapësirën e emrave nën /etc/netns/NAME/resolv.conf dhe lërini nisësin ta paraqesë. Mbajeni minimal: një ose dy serverë të arritshëm dhe domenet e kërkimit që i nevojiten detyrës. Mos e modifikoni skedarin e zgjidhësit të gjeneruar të hostit për të rregulluar një pamje të destinuar për një grup procesesh, sepse kjo ndryshon çdo aplikacion në makinë. Nëse hosti përdor një menaxher zgjidhësi, konfiguroni rrugën e hapësirës së emrave përmes atij menaxheri në vend që të luftoni me të.

Regjistroni përmbajtjen e skedarit në runbook. Përndryshe personi tjetër do të testojë zgjidhësin e hostit, do të shohë një përgjigje që funksionon dhe do të përfundojë se hapësira e emrave është në rregull.

Ritestoni të gjithë rrugën

Testoni brenda hapësirës së emrave me një adresë numerike, një emër të brendshëm dhe një emër publik. Ai sekuencë ndan arritshmërinë nga zgjidhja dhe ndan zonat e brendshme nga ato publike. Më pas rikrijoni hapësirën e emrave dhe përsëritni, sepse një skedar që ekziston vetëm në një instancë që punon zhduket me të.

Konfirmoni se skedarin e merr procesi, jo shell-i. Një kërkim që funksionon nga një shell interaktiv dhe dështon nga një shërbim është një gjetje për kontekstin e montimit, dhe ia vlen të shkruhet para incidentit të radhës në vend që të rizbuloni nga e para.