A VPN DNS működik, de a .local nevek továbbra is meghiúsulnak: ki oldja fel őket?

Két gép ugyanazon a VPN-en, ugyanaz a gazdanév, és csak az egyik oldja fel: a különbség általában nem az alagút, hanem hogy melyik feloldó válaszolt. Linux asztali gépen ez a név átmehet a névszolgáltatás-kapcsolón, a systemd-resolved stubján vagy egy olyan feloldón, amelyet az alkalmazás magával hozott, és mindegyik a saját szabályát alkalmazza ugyanarra az utótagra. Az utótagnál válnak szét a szabályok, mert a .local nem semleges címke. Derítse ki, melyik útvonalat járja valójában a meghiúsuló program, mielőtt megváltoztatja azt a sorrendet, amelyben bármi fut.

Két feloldó, két különböző válasz

A hagyományos glibc-keresés végigmegy a nsswitch.conf hosts: során, és sorra kérdez minden modult, amíg egy válaszol. A stub listeneren keresztül a systemd-resolveddel beszélő kliens ehelyett egyetlen folyamatot kérdez, és az a folyamat kapcsolatonkénti szabályzatot plusz a saját különleges eseteit alkalmazza. Az az alkalmazás, amely saját feloldót hoz, vagy olyan könyvtárat linkel, amely ezt teszi, mindkettőt megkerülheti. Egy gazdanévnek tehát három tulajdonosa lehet egy gépen, és csak egy tudja közülük, mit akart a VPN.

Azonosítsa a tulajdonost, mielőtt bármit megváltoztat, mert a javítás mindhárom esetben más. Egy böngésző és egy parancssori eszköz ugyanazon az asztali gépen jogosan lehet ellentétes véleményen, és ez az ellentét a nyom, nem a hiba. Ha a böngésző feloldja a nevet, az eszköz pedig nem, akkor feloldóútvonalat hibakeres, nem VPN-útvonalat. Erősítse meg az útvonalat külön, hogy egy útválasztási hiba ne legyen összetéveszthető névszolgáltatási hibával. Ha mindkettő egyetért, a hiba a gazda fölött van, és az itteni feloldókonfiguráció nem ér meg még egy szerkesztést.

Melyik parancs kérdezte meg valójában a feloldót

Két csak olvasható parancs válaszol összefüggő kérdésekre, és összehasonlításuk gyorsabban lokalizálja a problémát, mint a konfiguráció olvasása. Használjon valódi belső nevet, és tartsa privátan a kimenetet, mert a belső rekordok továbbra is belsők. Futtassa mindkettőt ugyanabban a munkamenetben, amelyben a meghiúsuló program fut:

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

Az első a konfigurált modulokon keresztül kérdez, amit egy tipikus program tapasztal. A második közvetlenül a systemd-resolvedtól kérdez, és jelenti a kapcsolatot, a protokollt és a válaszoló kiszolgálót. A vállalati kiszolgáló cím szerinti lekérdezése csak azt bizonyítja, hogy a kiszolgálónál megvan a rekord, mert semmit sem mond arról, hogy az alkalmazás valaha kérdezte-e. Olvassa el a VPN-t hordozó kapcsolatot és az általa igényelt tartományokat, majd hasonlítsa össze ezt a listát a meghiúsuló név utótagjával.

Miért kerüli el a .local az unicast zónáját

a systemd-resolved referenciája azt állítja, hogy a .local végződésű, többcímkés nevek mDNS engedélyezése esetén általában multicast DNS-hez mennek, nem a szokásos unicast DNS-hez. Az RFC 6762 ezt a névteret a link-local multicast számára tartja fenn, így egy vállalati zóna olyan helyes rekordot is tarthat, amelyet soha nem kérdeznek meg erről az utótagról. Az alagút tökéletesen irányíthatja a feloldót, és mégis elveszítheti a versenyt. Egy gyorsítótárból sikeres ping semmit sem mond az éppen lezajlott keresésről.

Van egy dokumentált kivétel, és ez dönti el ezek többségét: amikor egy kapcsolat ezt az utótagot keresési tartományként vagy útválasztási tartományként deklarálja, a démon az unicast útvonalon tartja, és kihagyja a multicast különleges esetét. Ez kapcsolatonkénti szabályzat, nem globális preferencia. Két gép ugyanazzal a VPN-kiszolgálóval eltérően viselkedhet, ha az egyik hálózati profil deklarálja a tartományt, a másik nem, ezért az aktív profilt olvassa, ne azt, amelyet emlékezete szerint szerkesztett.

A szűk kivétel legyőzi a globális átrendezést

Egy meglévő zónához, amelyet nem tud átnevezni, kérje meg a feloldó és a VPN tulajdonosait, hogy deklarálják a tartományt azon a kapcsolaton, amely hordozza. Az útválasztási tartomány bejegyzése ehhez az egy utótaghoz plusz a tervezett kiszolgálócím kis változás névvel ellátott tulajdonossal, és a kapcsolattal él, nem egy kézzel szerkesztett fájlban.

Túléli a bontást is, mert a kapcsolat szabályzata újra alkalmazódik, amikor a kapcsolat visszatér. A megosztott nsswitch.conf szerkesztése a csábító és a drágább alternatíva, mert megváltoztatja a keresési viselkedést a gépen minden névre, a helyi felderítést is beleértve. A multicast démon letiltása sem egyenértékű: eltávolítja a helyi viselkedést anélkül, hogy bármelyik feloldónak megtanítaná a vállalati zónát. Ha a szolgáltatás új, és nem örökölt, tegye egy olyan altartomány alá, amelyet a szervezete ellenőriz, és hagyja ki teljesen a versenyt. A szűk kivételt válassza, amikor a nevet firmware rögzíti vagy címkére nyomtatták, és új altartományt válasszon, amikor még mindig Ön ellenőrzi a klienst.

Mit kell bizonyítani a változtatás után

A javítást az alkalmazás saját keresésével bizonyítsa, ne egy teszteléshez telepített eszközzel, és töröljön minden gyorsítótárat, amely helyette válaszolhatna. Ezután erősítse meg a feloldó útvonalát és a választ adó kapcsolatot. Végül ellenőrizze, hogy a helyi felderítés úgy viselkedik-e, mint a változtatás előtt, mert a nyomtató, amely eltűnik, az a rész, amelyet az emberek legutoljára vesznek észre. Ez a három parancs a nevet, az útvonalat és a TLS-identitást ebben a sorrendben ellenőrzi:

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

A helyes cím rossz tanúsítvánnyal továbbra is elbuktat egy szigorú klienst, ezért ellenőrizze az alkalmazás által várt nevet, amikor a feloldás működik. Erősítse meg, hogy a szolgáltatás a VPN-címről is fogad kapcsolatokat, nem csak az irodai tartományból. Írja be a tartomány hatókörét, a kiszolgálót és a tulajdonost a kapcsolat dokumentációjába. Különben a következő ember, aki ezzel a hibával találkozik, ugyanahhoz a globális szerkesztéshez nyúl, amelyet éppen elkerült.