Hogyan vizsgáljuk meg a Mac VPN-en használt DNS-feloldóit

A scutil --dns azt a feloldókonfigurációt írja ki, amelyet a macOS valóban használ, nem az egyetlen DNS-szervert, amelyet egy beállításpanelen beírtál. A kimenet hosszabb, mint a legtöbben várják, mert a rendszer külön feloldóblokkokat tart az alapértelmezett útvonalhoz, a hatókörrel rendelkező interfészekhez és a tartományspecifikus továbbításhoz. A kimenet tetején lévő blokk nem feltétlenül az, amelyik a lekérdezésre válaszol. Ha egy privát név az irodában feloldódik, és abban a pillanatban meghiúsul, amikor a VPN feljön, az eltérés az illesztési szabályokban és az útvonalakban van, nem a szerver címében. Először a sorrendet olvasd el, aztán bizonyítsd a választ egy valódi lekérdezéssel.

A címek előtt olvasd el a blokkok sorrendjét

Minden bejegyzés a resolver #N jelöléssel nyílik, és felsorolja a nameserver[0], néha a if_index, egy flags sort, a reach, és ha a blokk nem egyszerű alapértelmezés, egy domain és egy search domain listát. Az 1-es számú, tartomány nélküli feloldó az alapértelmezett, amely a nyilvános neveket kezeli. Minden, ami a jelzőiben Scoped jelet hordoz, ahhoz az interfészhez kötődik, amelyet a if_index megnevez, és minden Supplemental jelöléssel ellátott dolog csak az alatta felsorolt tartományokra vonatkozik.

A kiválasztás utótag-egyeztetés. Egy intranet.corp.example szerű névhez a macOS azt a feloldót részesíti előnyben, amelynek domain bejegyzése a leghosszabb egyező utótag, így egy domain : corp.example tartalmú blokk akkor is legyőzi az alapértelmezettet, ha nagyon lent áll a kimenetben. A order dönt az azonos hosszúságú tartományok közötti egyenlőségről. Egy első pillantás ritkán igényel többet: a teljes kimenetet, ha egy blokkot elejétől végéig akarsz olvasni, a nyitó sorokat a blokksorrend megismeréséhez, és egy szűrt átfutást, amely a blokkfejléceket a mezősorok mellé írja. A hatókörrel rendelkező blokkok a saját fejlécük alatt jelennek meg, és a felettük lévő lista folytatásaként olvashatók, ezért tarts szem előtt egy fejlécet, amikor a kimenetet idézed.

scutil --dns
scutil --dns | sed -n '1,45p'
scutil --dns | grep -nE '^resolver #|^DNS configuration'
scutil --dns | grep -nE 'resolver #[0-9]+|if_index|domain|flags|nameserver'

Rendeld az if_index-et az alagút interfészéhez

Egy index csak akkor hasznos, ha meg tudod nevezni a mögötte lévő interfészt. A scutil --nwi felsorolja a rendszer által tárolt hálózati információkat, beleértve az elsődleges interfészt és az elérhetőséget, míg a ifconfig -l megadja a neveket, ahol a utun0 és a utun9 között azok az alagútjelöltek, amelyeket egy kliens általában létrehoz. Az Apple a scutil --dns eszközt használja saját vizsgálati példájaként a telepítési útmutatóban, és dokumentálja, hogyan tud a Network Extension kiválasztott tartományokat kiválasztott feloldókhoz irányítani, és pontosan ez az a mechanizmus, amelyet ezek a hatókörrel rendelkező blokkok felfednek.

A kérdést eldöntő ellenőrzés az, hogy a feloldó azon az útvonalon ül-e, amelyet az alagút telepített:

scutil --nwi
ifconfig utun4
route -n get 10.20.0.53
netstat -rn | grep -m5 utun

Ha a route -n get olyan átjárót és interfészt ad vissza, amelyek nem egyeznek a feloldó bejegyzésével, a cím teljesen helyes lehet, és mégis elérhetetlen. Egy osztott alagút, amely csak a vállalati alhálózatokat szállítja, eldobja a rajtuk kívüli DNS-szerver felé irányuló lekérdezéseket, és a hiba időtúllépésként jelentkezik, ezért a konfigurációs kimenet továbbra is tisztának tűnik.

Kérdezd a rendszer feloldóját, aztán a szervert

Három eszköz három különböző kérdésre válaszol, és összekeverésük okozza az ezen a területen előforduló téves következtetések többségét. A dscacheutil -q host -a name ugyanazon a rendszerfeloldón megy keresztül, amelyet a közönséges alkalmazások használnak, így a hatókörrel rendelkező és a kiegészítő blokkok érvényesek. A dig szerverargumentum nélkül a /etc/resolv.conf fájlt olvassa, amely nem az igazság forrása a macOS hatókörös feloldásához, és teljesen kihagyja a tartományonkénti szabályokat. A dig @address pontosan egy szervert ér el, és semmit sem mond a kiválasztásról.

dscacheutil -q host -a name intranet.corp.example
dig intranet.corp.example
dig @10.20.0.53 intranet.corp.example
nslookup intranet.corp.example

Amikor az első parancs válaszol, a második pedig NXDOMAIN-t ad vissza, megtaláltad a keresett felosztást, és semmi sem hibás. Amikor az első időtúllépéssel végződik, miközben a dig @10.20.0.53 válaszol, a feloldó működik, de az alagút által választott útvonalon nem érhető el, ezért a következő lépés a route -n get, és nem a DNS-beállítások szerkesztése. Tartsd a privát neveket mindenen kívül, amit jegybe vagy megosztott feljegyzésbe illesztesz.

Amit a kimenet nem tud megmutatni

Több réteg ül a feloldólista felett vagy mellett, és mindegyik elküldhet egy lekérdezést valahová, amit a kimenet soha nem említ. Egy biztonságos DNS-sel rendelkező böngésző a saját titkosított csatornáján oldhat fel, így egy oldal, amely betöltődik, miközben a dscacheutil időtúllépést szenved, nem ellentmondás. A biztonsági szoftver által telepített DNS-proxy Network Extension-szolgáltatóként fut, és maga továbbítja a lekérdezéseket, a scutil --dns pedig azt mutatja, mi volt beállítva, nem azt a felsőbb címet, amelyet a proxy végül használt. A keresési tartományok harmadik csavart adnak: a nem minősített névhez sorban hozzáfűződik minden felsorolt utótag, így a válaszoló blokk olyan is lehet, amelyre soha nem gyanakodtál.

Az elavult válaszok kizárása a legolcsóbb, és ezeket hagyják ki a leggyakrabban:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
scutil --dns | head -20

Ha a kimenet a tisztítás után megváltozik, az állapot gyorsítótárban volt, és a korábbi kimenet egy már nem létező alagutat írt le. Ha nem változik, a konfiguráció olyan, amilyen, és a kérdés az útvonalakra és az alkalmazáspolitikára tevődik át.

Rövid útmutató előtte és utána

Csak ott rögzíts kiindulási állapotot, ahol a szabályzat engedi, és tartsd a fájlokat minden szinkronizált mappán kívül. Az alábbi sorrend az, amit ügyfélgépeken futtatok: rögzítsd a kiindulási állapotot, csatlakozz, rögzítsd újra, majd hasonlítsd össze és keress.

scutil --dns > ~/dns-before.txt
# connect the VPN, then:
scutil --dns > ~/dns-after.txt
diff -u ~/dns-before.txt ~/dns-after.txt
dscacheutil -q host -a name intranet.corp.example

A különbséget blokkonként olvasd, ne soronként. Az elvárt forma egy új, hatókörrel rendelkező feloldó, amely hordozza az alagút interfészének indexét és egy domain bejegyzést a privát utótaghoz. Egy új alapértelmezett feloldó, amely nyilvános címre mutat, olyan lelet, amelyet érdemes felvetni annak, aki az ügyfélprofilt birtokolja. Ezután ismételd meg a lekérdezést abban az alkalmazásban, amely valóban meghiúsult, ne csak a héjban, és jegyezd fel a route -n get interfészét az eredmény mellé.

Egy változtatás visszavonásához bontsd a kapcsolatot, és ismételd meg a kiindulási állapot rögzítését. Ha a hatókörrel rendelkező blokk eltűnt, a kliens kitakarított maga után. Ha a blokk továbbra is egy már nem létező interfészhez van listázva, az állapot elavult, és egy tisztítás plusz újracsatlakozás a legkíméletesebb javítás, mielőtt bárki hozzányúlna a profilhoz.

Négy ellenőrzés ebben a sorrendben: illeszkedik-e valamelyik feloldóblokk a név leghosszabb utótagjához; ahhoz az interfészhez van-e kötve a blokk, amelyet az alagút telepített; az alagutat használja-e a névszerveréhez vezető útvonal; és a rendszer feloldója adja-e vissza a választ, nem a dig. Az első meghiúsuló ellenőrzés megmondja, hogy a DNS-szabályzatot, az alagút útvonalait vagy az alkalmazást kell-e módosítani. Ha mind a négy átmegy, és a név továbbra is meghiúsul, a probléma a DNS felett van, és a következő, amit meg kell vizsgálni, az, ami előtte az 53-as porton válaszol.