A VPN-ed három DNS-kiszolgálót küld: melyik válaszol?

Csatlakozás után nyisd meg a beállítások oldalát, és három DNS-cím jelenik meg; az audit kérdése az, melyik kezelte az utolsó lekérdezésedet. A szám önmagában semmire sem válaszol, mert a kliens továbbítása, egy fizikai interfész és egy tartományonkénti szabályzat ugyanabba a nézetbe ír. Ezek a bejegyzések különböző hatóköröket hordoznak, és nem a helyzet, hanem a hatókör dönti el, ki válaszol. Kezdd a források szétválasztásával, majd teszteld azt, amelyik a számodra fontos nevet birtokolja.

Miért hosszabb a lista a profilodnál

A VPN-kliens feloldócímeket továbbít az alagút kapcsolatához, az operációs rendszer pedig azok mellett tartja őket, amije a fizikai interfésznek már volt. Egy router, egy vállalati DHCP-bérlet, egy második VPN és egy tartományonkénti szabályzat külön bejegyzéssel járul hozzá. Ezért az oldalon látható három cím három hatókört jelenthet, nem három jelöltet egy feladatra. A számot szivárgás bizonyítékaként olvasni ennek az auditnak az első hibája.

Egy interfészen belül a kliens valóban sorrendben próbálja a kiszolgálóit, tehát a rendezett lista nem értelmetlen. Ami nem sor, az az egyesített nézet, ahol a profil, a fizikai kapcsolat és a tartományonkénti szabályok bejegyzései egyetlen rangsor nélkül állnak egymás mellett. Ez a különbség dönti el, mit tesztelsz: a sorrend egy hatókörön belüli viselkedést magyaráz, a hatókör pedig minden mást.

A titkosított DNS az alkalmazás belsejéből töri meg a képet. Egy böngésző vagy csevegőklien, amely saját DNS-over-HTTPS-feloldóval rendelkezik, a lekérdezéseket teljesen az operációs rendszer listája mellett küldi, így a beállítások oldalán látható címek olyan forgalmat írnak le, amelyet az alkalmazás soha nem generált. Ellenőrizd az alkalmazás saját feloldóbeállítását, mielőtt a profilt hibáztatnád egy rosszul kijött névért.

Mit mond a három ellenőrzés mindegyike

Minden forrás más helyen hagyja a nyomát, és egyetlen parancs sem mutatja meg mindet. Ez az a leképezés, amelyet érdemes a beállítások oldala mellett tartani:

Egy systemd-resolved-et használó rendszeren a resolvectl status a mérvadó, mert kapcsolatonként jelenti a DNS-t az útválasztási tartományokkal együtt. A macOS a scutil --dns-on keresztül válaszol, amely a hatókörrel rendelkező feloldókat a próbálkozás sorrendjében listázza. A Windows két felére bontja: Get-DnsClientServerAddress az interfészenkénti kiszolgálókhoz és Get-DnsClientNrptPolicy az utótag-szabályokhoz. A ténylegesen használt feloldóhoz tartozó parancsot futtasd, mert egy konténer-futtatókörnyezettel és asztali feloldóval rendelkező gépen egynél több is telepítve lehet.

Tartalék feloldó, amely nem tud válaszolni a zónádra

A második bejegyzés általában a rendelkezésre állás miatt van ott, és a rendelkezésre állás csak akkor működik, ha a tartalék ismeri a neveket. Kérdezz meg egy nyilvános feloldót egy belső gépnévről, és NXDOMAIN-t ad vissza, vagy egy vadkártyás választ egy olyan keresési tartományból, amelynek semmi köze hozzád. Egy senki által nem ellenőrzött átváltás aztán pont abban a pillanatban okoz kiesést, amikor szükség van rá.

A Split DNS éppen ezt hivatott megakadályozni: a vállalati utótagok egy zónát tartó feloldóhoz mennek, a nyilvános nevek pedig az alapértelmezett úton maradnak. A tervezés szilárd, és azon múlik, hogy az utótaglista teljes legyen. A Microsoft dokumentálja az utatagonkénti feloldószabályzatot, amely ezt Windows alatt vezérli, és ugyanez az ötlet útválasztási tartományként jelenik meg a systemd-resolvedben és hatókörrel rendelkező feloldóként a macOS-en.

Hasonlítsd össze azokat a zónákat, amelyekre a tartalék válaszolhat, a szabályzatban szereplő utótagokkal. Ez az összehasonlítás még azelőtt megtalálja a rést, hogy egy felhasználó jelezné, hogy egy belső oldal egy alagútváltás után nem oldódik fel.

Az operációs rendszer feloldóján keresztül kérdezz, ne körülötte

Az operációs rendszer feloldóján keresztül kérdezz, mert a kiszolgáló közvetlen lekérdezése megkerüli a szabályzatot, és csak azt jelenti, amit az a kiszolgáló mondana. A két válasz közötti rés maga a lényeg:

resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53

Ha a rendszerlekérdezés privát címet ad vissza, míg a közvetlen lekérdezés NXDOMAIN-t, a szabályzat működik, és a tartalék a gyenge pont. Ha mindkettő ugyanazt a nyilvános választ adja, a név a szándékolt hatókörön kívül oldódik fel, és az utótaglista az, ahol keresni kell. Mindkét kimenetet őrizd meg, mert egy feloldóvita két sorral gyorsabban rendeződik, mint a beállítások oldalának képernyőképével.

Utána gyakorold a hibaútit, mert egy senki által nem tesztelt tartalék csak feltevés. Tedd a preferált feloldót fekete lyukká egy lekérdezés erejéig, és figyeld, melyik cím jön vissza:

ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32

Töröld azt az útvonalat, amint a lekérdezés véget ér, különben a következő ember örököl egy rejtélyt. Ha a belső nevek abban az ablakban még feloldódnak, valami a szándékolt hatókörön kívül válaszolt rájuk. Ha inkább lejár az idejük, a tartalék hiányzik vagy megfelelően korlátozott, és a feloldó saját naplója megmondja, melyik kettő volt.

Döntsd el: megtartás, korlátozás vagy eltávolítás

Tarts meg egy második feloldót, ha a szükséges névteret válaszolja meg, és elérhető marad a profil alatt. Korlátozd, ha csak egy utótagot láthat és semmi mást, és távolítsd el, ha sem hatóköre, sem dokumentált célja nincs. A munka nélküli bejegyzés haszon nélküli jövőbeli szivárgás, a szállítói alapértelmezés pedig nem cél.

Rögzítsd az eredményt négy oszlopban: utótag, feloldó, interfész és tulajdonos. Ez a sor gyorsabban válaszolja meg a következő auditkérdést bármely képernyőképnél, és túléli azt a kliensfrissítést, amely csendesen átrendezi a listát.