ip netns exec en DNS: wêrom’t nammen binnen de nammeromte mislearje

In opdracht berikt 10.8.0.5 binnen de VPN-namromte sûnder klachten, en deselde opdracht mislearret op it stuit dat er in hostnamme brûkt. De nammeromte hat syn eigen ynterfaces, rûtes en sockets; hy hat gjin eigen resolvertriem. As der neat ien dêrhinne set, lêst it proses binnen de /etc/resolv.conf fan ’e host en freget in tsjinner dy’t miskien net berikber is fanôf dy netwurkstapel.

Dat is in triemkarprobleem en gjin rûteprobleem, en dêrom wurket de numerike bestimming noch altyd.

Kontrolearje it resolverbyld dat it proses echt krijt

Nim net oan dat de shell dy’t jo brûkten itselde is as it proses dat jo debugge. In grafyske applikaasje, in systemd-ienheid en in kontener kinne elk in oare mount- of netwurkkontekst yngeane. Fier de opfraach út fia deselde startrûte, en printsje de resolvertriem fan binnenút.

Foar in nammeromte makke mei ip netns add is de allinnich-lêzen-kontrôle koart:

ip netns exec vpn cat /etc/resolv.conf

Tink derop oft it resultaat in berikber adres, in loopback-stub of in symboalyske keppeling neamt dy’t nei in plak mei oare berikberens wiist.

Wat de exec-helper echt mountet

It ark ip-netns dokumintearret konfiguraasje per nammeromte ûnder /etc/netns/NAME/. As it in proses start, makket de helper in mountnammeromte en mountet dy triemmen oer har gewoane paden, sadat it proses de nammeromte-spesifike kopy sjocht. Dat is in gemak fan krekt dizze starter. It yngean fan in netwurknammeromte fia in oare rûte, lykas unshare of in kontener-runtime, reprodusearret dat net automatysk.

De loopback-resolver is hjir de falstrik: 127.0.0.53 betsjut de eigen loopback fan ’e nammeromte, net de stub fan ’e host. In stub dy’t allinnich yn ’e hostnammeromte harket, wurdt gjin tsjinst yn ’e nije.

Kies in resolver dy’t de nammeromte berikke kin

Hokker tsjinner de triem ek neamt, hy hat noch altyd in rûte fanôf dy nammeromte nedich. In iepenbiere resolver kin iepenbiere nammen beäntwurdzje en dochs foar in ynterne sône mislearje, om’t de partikuliere tsjinst allinnich fia de tunnel berikber is. Kontrolearje de rûte tagelyk mei it adres, net neidat de opfraach al mislearre is.

Applikaasjes mei har eigen resolver, lykas ien dy’t DNS oer HTTPS brûkt, kinne de triem folslein negearje. As it ark syn eigen DNS-ynstelling hat, sil it feroarjen fan resolv.conf dêr neat oan feroarje, en de nammeromte wie nea it probleem.

Skriuw de triem op it goede plak

Meitsje de triem per nammeromte ûnder /etc/netns/NAME/resolv.conf en lit de starter him presintearje. Hâld him minimaal: ien of twa berikbere tsjinners en de sykdomeinen dy’t de taak nedich hat. Bewurkje net de generearre resolvertriem fan ’e host om in byld foar ien groep prosessen te reparearjen, want dat feroaret elke applikaasje op ’e masine. As de host in resolverbehearder brûkt, konfigurearje dan it nammeromtepaad fia dy behearder ynstee fan der tsjin te fjochtsjen.

Skriuw de ynhâld fan ’e triem yn it runbook. Oars testet de folgjende persoan de resolver fan ’e host, sjocht in antwurd dat wurket en konkludearret dat de nammeromte yn oarder is.

Test it hiele paad opnij

Test binnen de nammeromte mei in numerik adres, in ynterne namme en in iepenbiere namme. Dy folchoarder skiedt berikberens fan resolúsje en skiedt ynterne sônes fan iepenbiere. Meitsje dêrnei de nammeromte opnij en werhelje, want in triem dy’t allinnich yn in draaiende eksimplaar bestiet, ferdwynt der mei.

Befêstigje dat it proses, net de shell, de triem krijt. In opfraach dy’t fan in ynteraktive shell út wurket en fan in tsjinst út mislearret, is in befinning oer de mountkontekst, en it is de muoite wurdich om dy foar it folgjende ynsidint op te skriuwen ynstee fan him fan nul ôf wer te ûntdekken.