ip netns exec és DNS: miért vallanak kudarcot a nevek a névtéren belül

Egy parancs panasz nélkül eléri a 10.8.0.5 címet a VPN névterében, és ugyanez a parancs abban a pillanatban elbukik, amikor hosztnevet használ. A névtérnek saját interfészei, útvonalai és socketjei vannak; saját feloldófájlja nincs. Hacsak valami nem tesz oda egyet, a benne futó folyamat a hoszt /etc/resolv.conf fájlját olvassa, és olyan szervert kérdez, amely esetleg nem érhető el abból a hálózati veremből.

Ez fájlválasztási probléma, nem útvonalválasztási probléma, és éppen ezért működik továbbra is a numerikus cél.

Ellenőrizze a feloldó nézetét, amelyet a folyamat valóban megkap

Ne feltételezze, hogy a használt shell megegyezik a hibakeresett folyamattal. Egy grafikus alkalmazás, egy systemd-egység és egy konténer mindegyike más csatolási vagy hálózati környezetbe léphet be. Futtassa a lekérdezést ugyanazon az indítási útvonalon, és nyomtassa ki a feloldófájlt belülről.

A ip netns add paranccsal létrehozott névtér esetében a csak olvasható ellenőrzés rövid:

ip netns exec vpn cat /etc/resolv.conf

Figyelje meg, hogy az eredmény elérhető címet, loopback-stubot vagy más elérhetőségű helyre mutató szimbolikus hivatkozást nevez-e meg.

Mit csatol valójában az exec-segéd

Az ip-netns eszköz névtérenkénti konfigurációt dokumentál a /etc/netns/NAME/ alatt. Amikor folyamatot indít, a segéd csatolási névteret hoz létre, és ezeket a fájlokat a szokásos útvonalaik fölé csatolja, így a folyamat a névtérre jellemző másolatot látja. Ez ennek a konkrét indítónak a kényelme. Hálózati névtérbe más úton belépni, például unshare-tal vagy konténer-futtatókörnyezettel, nem reprodukálja ezt automatikusan.

Itt a loopback feloldó a csapda: a 127.0.0.53 a névtér saját loopbackjét jelenti, nem a hoszt stubját. Az a stub, amely csak a hoszt névterében figyel, nem válik szolgáltatássá az újban.

Válasszon olyan feloldót, amelyet a névtér el tud érni

Bármelyik szervert nevezi is meg a fájl, továbbra is kell egy útvonal abból a névtérből. Egy nyilvános feloldó válaszolhat nyilvános nevekre, és mégis elbukhat egy belső zóna esetén, mert a privát szolgáltatás csak az alagúton át érhető el. Az útvonalat a címmel egy időben ellenőrizze, ne azután, hogy a lekérdezés már elbukott.

A saját feloldóval rendelkező alkalmazások, például a DNS over HTTPS-t használó, teljesen figyelmen kívül hagyhatják a fájlt. Ha az eszköznek saját DNS-beállítása van, a resolv.conf módosítása nem hat rá, és a névtér soha nem volt a probléma.

Írja a fájlt a megfelelő helyre

Hozza létre a névtérenkénti fájlt a /etc/netns/NAME/resolv.conf alatt, és hagyja, hogy az indító bemutassa. Tartsa minimálisan: egy vagy két elérhető szerver és a feladat által igényelt keresési tartományok. Ne szerkessze a hoszt generált feloldófájlját egy folyamatcsoportnak szánt nézet javításához, mert az a gépen minden alkalmazást megváltoztat. Ha a hoszt feloldókezelőt használ, a névtér útvonalát azon a kezelőn keresztül állítsa be, ahelyett hogy harcolna vele.

Jegyezze fel a fájl tartalmát a runbookba. Különben a következő ember teszteli a hoszt feloldóját, működő választ lát, és arra a következtetésre jut, hogy a névtér rendben van.

Tesztelje újra a teljes útvonalat

Teszteljen a névtéren belül numerikus címmel, belső névvel és nyilvános névvel. Ez a sorrend elválasztja az elérhetőséget a feloldástól, és elválasztja a belső zónákat a nyilvánosaktól. Ezután hozza létre újra a névteret, és ismételje meg, mert egy csak futó példányban létező fájl eltűnik vele.

Erősítse meg, hogy a folyamat, nem a shell kapja meg a fájlt. Az a lekérdezés, amely interaktív shellből működik és szolgáltatásból elbukik, csatolási környezetre vonatkozó megállapítás, és érdemes leírni a következő incidens előtt, ahelyett hogy nulláról újra felfedezné.