Miért nem éri el a /etc/hosts bejegyzésed a VPN DNS-ét

Hozzáadtál egy nevet a /etc/hosts fájlhoz, csatlakoztál a VPN-hez, és arra számítottál, hogy a rekord mindenkinél megjelenik. Nem így történik, és a meglepetés általában egy második tünettel érkezik: a név a te gépeden feloldódik, egy kollégáén viszont nem, ami törött VPN DNS-szolgáltatásnak tűnik, valójában pedig a hosts fájl pontosan azt teszi, amire tervezték. A hosts fájl helyi névfeloldási konfiguráció, nem zónafrissítés, és egy normál VPN-kapcsolatban semmi nem tölti fel.

A hosts helyi felülírás, nem zónafrissítés

A fájl leképezések listája, amelyeket a névszolgáltatási könyvtárak a DNS-kiszolgáló megkérdezése előtt vagy helyette megnéznek. Egy olyan sor, mint a 10.40.0.20 build.corp.example, megváltoztatja, mire jutnak az alkalmazások azon az egy gépen. Nem hoz létre rekordot, nem utazik át az alagúton, és az a DNS-kiszolgáló, amelyre az alagút mutat, mit sem tud a létezéséről.

Ezért aszimmetrikus a hiba. Az ügyfeled választ kap a fájlból. Egy másik ügyfél megkérdezi a VPN DNS-kiszolgálóját, amely semmit nem ad vissza, és az alkalmazás azt jelenti, hogy a név nem létezik. Mindkét gép helyesen viselkedik; csak az egyiknek van olyan felülírása, amelyet a másik soha nem látott.

Két parancs, két különböző összetevő

A vita lezárásának leggyorsabb módja, ha láthatóvá teszed a különbséget két parancsban, mindkettőt azon az ügyfélen futtatva, amelyen ott van a hosts bejegyzés:

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

Az első a rendszer saját keresési útvonalát kérdezi, amely egy tipikus glibc rendszeren a DNS előtt helyi fájlokat olvas. A második DNS-lekérdezést küld közvetlenül az adott címen lévő kiszolgálónak, és egyáltalán nem néz helyi fájlokat. Amikor az első visszaadja a bejegyzésedet, a második pedig NXDOMAIN-t ad, bebizonyítottad, hogy a rekord nem létezik a DNS-ben, és hogy a géped helyi felülírásból válaszol.

A sorrend konfigurálható, és érdemes ellenőrizni, mielőtt bármit megállapítanál egy adott disztribúcióról. Nézd meg a hosts: sort a /etc/nsswitch.conf fájlban; a hosts: files dns először a fájlokat nézi. Ne másold azt a példát egy működő konfigurációra csak a sorrend megváltoztatásáért, mert a valódi rendszerek gyakran további forrásokat és feltételes szolgáltatásbejegyzéseket sorolnak fel, amelyeket a példa nem tartalmaz.

A systemd-resolved elmossa a tesztet

Egy systemd-resolvedet használó rendszeren a helyi stub a hosts adatbázisból is szolgál ki neveket. Ezért a 127.0.0.53 lekérdezése nem független tesztje a távoli kiszolgálónak, pedig úgy néz ki, mint egy DNS-lekérdezés, és úgy is viselkedik. Meg tudod erősíteni, mit tud a feloldó, és mely kiszolgálókat kérdezne meg ezzel:

resolvectl query build.corp.example
resolvectl status

A status kimenete kapcsolatonként nevezi meg a DNS-kiszolgálókat, és így tudod meg, hogy a VPN-kapcsolat egyáltalán kapott-e feloldót. Ez a kérdés elkülönül a hosts bejegyzéstől, és ezt érdemes feltenni, amikor egy privát név minden felhasználónál meghiúsul, nem csak egynél.

Az alkalmazások még egy réteget hozzáadhatnak. Egy saját DNS-over-HTTPS-beállítással rendelkező böngésző, egy saját feloldókonfigurációval rendelkező konténer vagy egy futtatókörnyezet, amely a folyamat teljes élettartama alatt gyorsítótárazza a kereséseket, külön-külön másképp válaszolhat, mint a rendszer. Teszteld azt az alkalmazást, amely fontos neked, ahelyett hogy feltételeznéd, hogy egyetlen parancs leírja a gépen futó összes programot.

Mi oszt meg valójában egy nevet a VPN-en keresztül

Ha egy privát névnek mindenkinél működnie kell, olyan tulajdonosra van szüksége, akit mindenki feloldója elér. A tiszta válasz az, hogy a rekordot egy felügyelt zónában tedd közzé, és azt a zónát a szándékolt VPN DNS-útvonalon feloldhatóvá tedd. Akkor a rekordnak egyetlen igazságforrása, auditnyoma és életciklusa van, és senkinek nem kell emlékeznie, melyik laptop hordoz helyi felülírást.

A hosts fájlok terjesztése jogos alternatíva, és ez végpontkezelés, nem névszolgáltatás. Ha ezt választod, a fájlt a flottát kezelő rendszernek kell telepítenie, verzióznia és eltávolítania, és a tervezésben így kell leírni. „A VPN kezeli” nem ennek a folyamatnak a leírása.

A dinamikus DNS-regisztráció harmadik mechanizmus, saját engedélyekkel, frissítés-hitelesítéssel és rekord-élettartammal. Nem következik egy hosts bejegyzésből, és nem következik abból sem, hogy egy ügyfél egyszerűen csatlakozik, hacsak a kiszolgáló és az ügyfél is nincs erre konfigurálva. Egy magától megjelenő rekord jele annak, hogy valaki engedélyezte a biztonságos frissítéseket, és egy ügyfél regisztrálja magát, és ez a konfiguráció a tervezési rekordba tartozik, nem egy hibakeresési szálba. Ha senki nem tudja megnevezni, kié ez a beállítás, kezeld az automatikus rekordot ellenőrizetlennek, és tartsd meg a felügyelt zónát igazságforrásként.

A feloldott név nem útvonal

A névfeloldás és az elérhetőség külön dolog, és az elavult helyi leképezés a klasszikus módja annak, hogy összekeverjük őket. Egy hosts bejegyzés, amely egy elköltözött címre mutat, továbbra is a régi gazdagépet választja jóval azután, hogy a DNS-t kijavították, és a tünet útválasztási hibának tűnik egy jól feloldódó néven.

Tehát amikor a jelentés az, hogy „a név feloldódik, de a szolgáltatás nem érhető el”, hasonlítsd össze a rendszerkeresést egy kifejezett, a VPN DNS-kiszolgálójához intézett lekérdezéssel, majd ellenőrizd a kapott címet azzal szemben, amelyet a szolgáltatás valóban használ. A systemd-resolved-referencia dokumentálja az általa megnézett helyi forrásokat, és ez az a térkép, amelyre ehhez az összehasonlításhoz szükséged van.

Utána javítsd ki a felülírást a tulajdonosán keresztül. Egy sor eltávolítása a saját hosts fájlodból semmit nem tesz azért a tizenkét laptopért, amely ugyanazt a sort kapta egy telepítési szkripttől, és valójában ez a probléma azon változata, amellyel az emberek találkoznak.