Miért mutatja a resolv.conf a VPN DNS-ét, ha a lekérdezések figyelmen kívül hagyják

A naplókban semmi sem tűnik hibásnak: az interfész aktív, a feloldó jelenti a VPN DNS-kiszolgálóját, és a lemezen lévő fájl felsorolja. Mégis egy belső gazdagépnév továbbra is a helyi útválasztón keresztül oldódik fel. A három állítás nem mond ellent egymásnak, mert a fájl, a kapcsolatonkénti állapot és a lekérdezés útvonala különböző objektumok, amelyek véletlenül közös nevet viselnek. A következőkben az az útvonal következik, amelyet egy lekérdezés valójában bejár egy systemd-resolvedet futtató gazdagépen.

Három objektum resolv.conf néven

Resolvedot futtató gazdagépen a /etc/resolv.conf általában szimbolikus hivatkozás a /run/systemd/resolve/stub-resolv.conf fájlra. Az a cél tartalmazza egy helyi stub-figyelő címét, 127.0.0.53, valamint a resolved által kiszámított keresési tartományokat. Ez a nézet az állapotról, nem maga az állapot.

Az állapot a resolved kapcsolatonkénti konfigurációjában él, ezért a resolvectl status ellentmondhat a fájlnak, és mégis igaza lehet. Minden kapcsolat a saját kiszolgálóit és a saját útválasztási tartományait hordozza, a stub pedig ezeket az adatokat nézi meg, amikor lekérdezés érkezik. A systemd-resolved kézikönyve leírja a generált fájlokat és a kapcsolatonkénti modellt; a nézet és az állapot szétválasztása az a rész, amit érdemes megjegyezni. A szimbolikus hivatkozás céljának módosítása azt változtatja meg, amit a hagyományos kliensek olvasnak, nem azt, amit a feloldó tud.

Egy harmadik objektum, a /run/systemd/resolve/resolv.conf, minden kapcsolatot egyetlen kiszolgálólistává lapít. Az erre a fájlra mutató program a lekérdezéseket egyenesen a felsorolt kiszolgálókra küldi, és kihagyja a stubot, így a kapcsolatonkénti szabályzat már nem vonatkozik rá. Ezért két program ugyanazon a gépen különbözően válaszolhat ugyanarra a névre, és egyik sem hibás.

Kövessen egy lekérdezést az NSS-en keresztül

A glibc a /etc/nsswitch.conf fájlt olvassa, hogy eldöntse, ki válaszol egy névre. A resolve-ot tartalmazó hosts-sor a kérdést a nss-resolve felé irányítja, amely D-Buson keresztül kérdezi a resolvedot, és megkapja a kapcsolatonkénti választ. A csak files dns-at tartalmazó sor a lekérdezést arra a címre küldi, amelyet a /etc/resolv.conf tart.

Ez az egy sor magyarázza a böngésző és a dig közötti nézeteltérések többségét. A dig közvetlenül olvassa a resolv.conf fájlt, és soha nem érinti az NSS-t, ezért a stubot vagy egy feljebb lévő kiszolgálót tesztel az alkalmazás útvonala helyett. A getent hosts internal.example az NSS-en halad át, és válaszának összevetése a dig válaszával az első hasznos mérés.

A saját feloldót magukkal hozó, vagy fix végponthoz HTTPS-en DNS-t beszélő alkalmazások mindkét útvonalat megkerülik. Semmi a resolv.conf-ben vagy a resolved állapotában nem korlátozza őket.

Ellenőrizze, kié a fájl, és hova mutat

Olvassa el a hivatkozási láncot, mielőtt bármit módosít, mert a tulajdon dönti el, melyik fájl a mérvadó. Az alábbi parancsok mindegyike csak állapotot olvas.

stat -c '%N' /etc/resolv.conf
resolvectl status --no-pager
grep '^hosts' /etc/nsswitch.conf
ls -l /run/systemd/resolve/

Az első sor együtt nyomtatja ki a hivatkozást és a célját, és a VPN-szkript tulajdonában lévő közönséges fájl azt jelenti, hogy a feloldó soha nem tekinti bemenetnek azt az írást. Az állapotkimenet felsorolja a kapcsolatonkénti kiszolgálókat, valamint azokat az útválasztási tartományokat, amelyek eldöntik, hova megy az egyes lekérdezés. Az nsswitch-sor megmondja, hogy a stubot egyáltalán megkérdezik-e, tehát a fájlban lévő stub-cím resolve nélkül azt jelenti, hogy a lekérdezések elérik a helyi figyelőt, miközben semmi sem kezeli a szétválasztást. Az utolsó lista is számít, mert a stub-resolv.conf nélküli gazdagép nem futtatja az itt leírt elrendezést.

Ha a lánc egy másik csomag által kezelt fájlban végződik, a VPN-kliens és az a csomag az a két tulajdonos, amelyet össze kell hangolni. A hivatkozás lecserélése eldobja az egyik tulajdonos munkáját, és a másikét a helyén hagyja.

Javítsa a hivatkozás tulajdonosánál

A VPN-kapcsolatnak a saját kapcsolatán kell regisztrálnia a kiszolgálóit és a tartományait, majd a bontáskor vissza kell vonnia azokat. A NetworkManager resolved-integrációja és az ügyfél saját segítője egyaránt így működik; az a szkript, amely csak a resolv.conf fájlt írja át, nem.

Egy már létező kapcsolaton a futásidejű beállítások mutatják meg a mechanizmust. A resolvectl dns tun0 10.40.0.53 kiszolgálót csatol, a resolvectl domain tun0 '~corp.example' pedig útválasztási tartományt. A tilde a teherhordó karakter: ennek az utótagnak a lekérdezéseit erre a kapcsolatra korlátozza, és minden mást békén hagy, míg ugyanaz az érték nélküle keresési tartománnyá válik, és a szétválasztás elpárolog. Azok a címek laboratóriumi példák, nem maradandó konfiguráció. Erősítse meg a resolvectl query host.corp.example segítségével, és olvassa ki, melyik kapcsolat válaszolt.

Egy regisztrált kiszolgálónak még mindig kell útvonal. Amikor a lekérdezés eléri a megfelelő kapcsolatot, és lejár az idő, a hiba nem a feloldó tulajdonában van, hanem az alagúton át való elérhetőségben.

Hogyan néz ki egy működő állapot

Az egészséges eredmény mindhárom nézetben összhangban van: a kapcsolatonkénti kiszolgálók megfelelnek annak, amit a VPN kiadott, az útválasztási tartományok csak belső utótagokat fednek le, és a fontos alkalmazás felold egy belső nevet, miközben a nyilvános név továbbra is a helyi útvonalat követi. Egyetlen sikeres lekérdezés kevesebbet bizonyít ennél az egyetértésnél.

Utána bontsa a kapcsolatot, és ismételje meg mindkét lekérdezést. Az a kliens, amely a bontás után is regisztrálva hagyja a tartományait, olyan gépet eredményez, amely órákkal később elbukik a belső feloldásokon, nyitott alagút és nyilvánvaló ok nélkül.