Kuidas kontrollida DNS-i lahendajaid, mida teie Mac VPN-is kasutab

scutil --dns trükib lahendaja seadistuse, mida macOS tegelikult küsib, mitte selle ühe DNS-serveri, mille te seadete paneeli kirjutasite. Väljund on pikem, kui enamik ootab, sest süsteem hoiab eraldi lahendaja plokke vaiketeekonna, ulatuslike liideste ja domeenipõhise edasisaatmise jaoks. Väljundi tipus olev plokk ei ole tingimata see, mis päringule vastab. Kui privaatne nimi laheneb kontoris ja ebaõnnestub hetkel, mil VPN tõuseb, on lahknevus sobitamisreeglites ja marsruutides, mitte serveri aadressis. Lugege kõigepealt järjekorda ja tõestage siis vastus päris päringuga.

Lugege plokkide järjekorda enne aadresse

Iga kirje algab resolver #N-ga ja loetleb nameserver[0], mõnikord if_index, rea flags, reach ja kui plokk ei ole tavaline vaikeväärtus, siis domain ja loendi search domain. Lahendaja number 1 ilma domeenita on vaikeväärtus, mis tegeleb avalike nimedega. Kõik, mis kannab oma lippudes Scoped, on seotud liidesega, mille nimetab if_index, ja kõik Supplemental-ga märgitud kehtib ainult selle all loetletud domeenide kohta.

Valik on sufiksi sobitamine. Nime puhul nagu intranet.corp.example eelistab macOS lahendajat, mille kirje domain on pikim sobiv sufiks, seega plokk, milles on domain : corp.example, võidab vaikeväärtuse ka siis, kui see asub väljundis väga all. order lahendab viigid sama pikkusega domeenide vahel. Esimene pilk vajab harva enamat: kogu väljundit, kui tahate ühte plokki algusest lõpuni lugeda, algread plokkide järjekorra õppimiseks ja filtreeritud läbiminek, mis trükib plokkide päised väljade ridade kõrvale. Ulatuslikud plokid ilmuvad oma pealkirja alla ja neid loetakse nende kohal oleva loendi jätkuna, seega hoidke pealkiri silma all, kui väljundit tsiteerite.

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'

Siduge if_index tunneliliidesega

Indeks on kasulik ainult siis, kui saate selle taga oleva liidese nimetada. scutil --nwi loetleb võrguinformatsiooni, mida süsteem hoiab, sealhulgas primaarse liidese ja kättesaadavuse, samal ajal kui ifconfig -l annab teile nimed, kus utun0 kuni utun9 on tunnelikandidaadid, mille klient tavaliselt loob. Apple kasutab scutil --dns oma kontrolli näitena juurutamisjuhendis, ja dokumenteerib, kuidas Network Extension saab suunata valitud domeene valitud lahendajatele, mis on mehhanism, mille need ulatuslikud plokid paljastavad.

Kontroll, mis küsimuse otsustab, on see, kas lahendaja asub teel, mille tunnel paigaldas:

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

Kui route -n get tagastab lüüsi ja liidese, mis ei vasta lahendaja kirjele, võib aadress olla täiesti õige ja siiski kättesaamatu. Jagatud tunnel, mis kannab ainult ettevõtte alavõrke, viskab kõrvale neist väljapoole suunatud päringud DNS-serverile, ja tõrge ilmneb ajutõrkena, mistõttu seadistuse väljund näeb jätkuvalt puhas välja.

Pärige süsteemi lahendajat, seejärel serverit

Kolm tööriista vastavad kolmele erinevale küsimusele ja nende segamine tekitab enamiku selles valdkonnas tehtud valedest järeldustest. dscacheutil -q host -a name läbib sama süsteemi lahendaja, mida kasutavad tavalised rakendused, seega kehtivad ulatuslikud ja täiendavad plokid. dig ilma serveri argumendita loeb /etc/resolv.conf, mis ei ole macOS-is ulatusliku lahendamise tõeallikas, ja jätab domeenipõhised reeglid täielikult vahele. dig @address jõuab täpselt ühe serverini ega ütle valiku kohta midagi.

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

Kui esimene käsk vastab ja teine tagastab NXDOMAIN, olete leidnud otsitava jagunemise ja miski ei ole katki. Kui esimene lõpeb ajutõrkega, samal ajal kui dig @10.20.0.53 vastab, töötab lahendaja, kuid ei ole kättesaadav teel, mille tunnel valis, seega on järgmine samm route -n get, mitte DNS-i seadete muutmine. Hoidke privaatsed nimed eemal kõigest, mille kleepite pileti või jagatud märkme sisse.

Mida väljund teile näidata ei saa

Mitmed kihid asuvad lahendajate loendi kohal või kõrval ja igaüks neist võib saata päringu kuhugi, mida väljund kunagi ei maini. Turvalise DNS-iga brauser võib lahendada oma krüpteeritud kanali kaudu, seega leht, mis laaditakse samal ajal, kui dscacheutil ajutõrkega lõpeb, ei ole vastuolu. Turbetarkvara paigaldatud DNS-puhverserver töötab Network Extensioni pakkujana ja edastab päringud ise, ning scutil --dns näitab, mis seadistati, mitte ülesvoolu aadressi, mida puhverserver lõpuks kasutas. Otsingudomeenid lisavad kolmanda nüansi: kvalifitseerimata nimele lisatakse iga loetletud sufiks järjekorras, seega vastanud plokk võib olla selline, mida te kunagi ei kahtlustanud.

Vanad vastused on kõige odavam välistada ja kõige sagedamini vahele jäetud:

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

Kui väljund muutub pärast tühjendamist, oli olek vahemällu salvestatud ja varasem väljund kirjeldas tunnelit, mida enam ei olnud. Kui see ei muutu, on seadistus selline, nagu ta on, ja küsimus liigub marsruutide ja rakendusepoliitika juurde.

Lühike juhend enne ja pärast

Salvestage baasjoon ainult seal, kus poliitika seda lubab, ja hoidke failid igast sünkroonitud kaustast väljas. Allpool olev järjestus on see, mida ma kliendimasinatel käivitan: salvesta baasjoon, ühenda, salvesta uuesti, seejärel võrdle ja otsi.

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

Lugege erinevust plokkide kaupa, mitte ridade kaupa. Uus ulatuslik lahendaja, mis kannab tunneli liidese indeksit ja privaatse sufiksi kirjet domain, on oodatud kuju. Uus vaikelahendaja, mis osutab avalikule aadressile, on leid, mida tasub tõstatada selle ees, kellele kliendiprofiil kuulub. Seejärel korrake päringut rakenduses, mis tegelikult ebaõnnestus, mitte ainult kestas, ja märkige liides route -n get-st tulemuse kõrvale.

Muudatuse tagasivõtmiseks katkestage ühendus ja korrake baasjoone salvestamist. Kui ulatuslik plokk on kadunud, on klient enda järel koristanud. Kui plokk on endiselt loetletud liidese vastu, mida enam ei ole, on olek vananenud, ja tühjendamine koos taasühendamisega on kõige õrnem parandus, enne kui keegi profiili puudutab.

Neli kontrolli selles järjekorras: kas mõni lahendaja plokk vastab nime pikimale sufiksile; kas see plokk on seotud liidesega, mille tunnel paigaldas; kas tee selle nimeserverini kasutab tunnelit; ja kas vastuse tagastab süsteemi lahendaja, mitte dig. Esimene kontroll, mis ebaõnnestub, ütleb teile, kas muuta DNS-poliitikat, tunneli marsruute või rakendust. Kui kõik neli läbivad ja nimi ikka ebaõnnestub, asub probleem DNS-ist kõrgemal, ja järgmine asi, mida uurida, on kõik, mis vastab selle ees pordile 53.