Kā pārbaudīt DNS risinātājus, ko jūsu Mac izmanto VPN

scutil --dns izdrukā risinātāja konfigurāciju, kurai macOS patiešām pievēršas, nevis to vienīgo DNS serveri, ko ievadījāt iestatījumu panelī. Izvade ir garāka, nekā vairums sagaida, jo sistēma glabā atsevišķus risinātāja blokus noklusējuma ceļam, ierobežotajām saskarnēm un domēnam raksturīgai pāradresācijai. Augšējais izvades bloks ne vienmēr ir tas, kas atbild uz vaicājumu. Ja privāts vārds birojā tiek atrisināts un neizdodas mirklī, kad VPN paceļas, neatbilstība ir saskaņošanas noteikumos un maršrutos, nevis servera adresē. Vispirms izlasiet kārtību, pēc tam pierādiet atbildi ar īstu meklēšanu.

Izlasiet bloku kārtību pirms adresēm

Katrs ieraksts sākas ar resolver #N un uzskaita nameserver[0], dažreiz if_index, flags rindu, reach un, ja bloks nav vienkāršs noklusējums, domain un search domain sarakstu. Risinātājs numur 1 bez domēna ir noklusējums, kas apkalpo publiskos vārdus. Viss, kam karodziņos ir Scoped, ir saistīts ar saskarni, ko nosauc if_index, un viss, kas atzīmēts ar Supplemental, attiecas tikai uz zem tā uzskaitītajiem domēniem.

Atlase ir sufiksa saskaņošana. Vārdam kā intranet.corp.example macOS dod priekšroku risinātājam, kura domain ieraksts ir garākais atbilstošais sufikss, tāpēc bloks ar domain : corp.example pārspēj noklusējumu pat tad, ja tas atrodas ļoti zemu izvadē. order izšķir vienāda garuma domēnu vienādības. Pirmajam skatienam reti vajag vairāk: visu izvadi, ja gribat izlasīt vienu bloku no sākuma līdz beigām, sākuma rindas bloku kārtības apguvei un filtrētu gājienu, kas izdrukā bloku virsrakstus līdzās lauku rindām. Ierobežotie bloki parādās zem sava virsraksta un lasās kā augstāk esošā saraksta turpinājums, tāpēc citējot izvadi vienmēr turiet virsrakstu acu priekšā.

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'

Sasaistiet if_index ar tuneļa saskarni

Indekss ir noderīgs tikai tad, ja varat nosaukt saskarni aiz tā. scutil --nwi uzskaita tīkla informāciju, ko sistēma glabā, tostarp primāro saskarni un sasniedzamību, bet ifconfig -l dod jums nosaukumus, kur utun0 līdz utun9 ir tuneļa kandidāti, ko klients parasti izveido. Apple izmanto scutil --dns kā savu pārbaudes piemēru izvietošanas rokasgrāmatā, un dokumentē, kā Network Extension var novirzīt atlasītos domēnus uz atlasītiem risinātājiem, un tieši šo mehānismu atklāj šie ierobežotie bloki.

Pārbaude, kas izšķir jautājumu, ir vai risinātājs atrodas ceļā, ko uzstādīja tunelis:

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

Ja route -n get atgriež vārteju un saskarni, kas neatbilst risinātāja ierakstam, adrese var būt pilnīgi pareiza un tomēr nesasniedzama. Sadalīts tunelis, kas pārvadā tikai uzņēmuma apakštīklus, izmet vaicājumus uz DNS serveri ārpus tiem, un kļūme izpaužas kā taimauts, tāpēc konfigurācijas izvade joprojām izskatās tīra.

Vaicājiet sistēmas risinātāju, pēc tam serveri

Trīs rīki atbild uz trim dažādiem jautājumiem, un to sajaukšana rada lielāko daļu nepareizo secinājumu šajā jomā. dscacheutil -q host -a name iet caur to pašu sistēmas risinātāju, ko izmanto parastas programmas, tāpēc darbojas ierobežotie un papildu bloki. dig bez servera argumenta lasa /etc/resolv.conf, kas macOS nav patiesības avots ierobežotai atrisināšanai, un pilnībā izlaiž noteikumus pa domēniem. dig @address sasniedz tieši vienu serveri un neko nepasaka par atlasi.

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

Kad pirmā komanda atbild un otrā atgriež NXDOMAIN, jūs esat atraduši meklēto sadalījumu un nekas nav salauzts. Kad pirmā beidzas ar taimautu, bet dig @10.20.0.53 atbild, risinātājs strādā, taču nav sasniedzams ceļā, ko izvēlējās tunelis, tāpēc nākamais solis ir route -n get, nevis DNS iestatījumu maiņa. Turiet privātos vārdus ārpus visa, ko ielīmējat biļetē vai koplietotā piezīmē.

Ko izvade nevar jums parādīt

Vairāki slāņi sēž virs risinātāju saraksta vai tam blakus, un katrs var nosūtīt vaicājumu tur, ko izvade nekad nemin. Pārlūks ar ieslēgtu drošo DNS var atrisināt pa savu šifrēto kanālu, tāpēc lapa, kas ielādējas, kamēr dscacheutil beidzas ar taimautu, nav pretruna. Drošības programmatūras uzstādīts DNS starpniekserveris darbojas kā Network Extension nodrošinātājs un pats pārsūta vaicājumus, un scutil --dns parāda, kas tika konfigurēts, nevis augšupējo adresi, ko starpniekserveris beigās izmantoja. Meklēšanas domēni pievieno trešo krokni: nekvalificētam vārdam pēc kārtas pievieno katru uzskaitīto sufiksu, tāpēc atbildējušais bloks var būt tāds, ko jūs nekad neesat aizdomās turējuši.

Novecojušas atbildes ir vislētāk izslēgt un visbiežāk izlaist:

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

Ja pēc notīrīšanas izvade mainās, stāvoklis bija kešatmiņā un iepriekšējā izvade aprakstīja tuneli, kura vairs nebija. Ja tā nemainās, konfigurācija ir tāda, kāda tā ir, un jautājums pāriet uz maršrutiem un programmu politiku.

Īsa rokasgrāmata pirms un pēc

Fiksējiet bāzes līniju tikai tur, kur politika atļauj, un turiet failus ārpus jebkuras sinhronizētas mapes. Zemāk esošā secība ir tā, ko es izpildu klientu datoros: fiksējiet bāzes līniju, pieslēdzieties, fiksējiet vēlreiz, pēc tam salīdziniet un meklējiet.

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

Lasiet atšķirību pa blokiem, nevis pa rindām. Paredzamā forma ir jauns ierobežots risinātājs, kas nes tuneļa saskarnes indeksu un domain ierakstu privātajam sufiksam. Jauns noklusējuma risinātājs, kas norāda uz publisku adresi, ir atradums, ko ir vērts izcelt tam, kam pieder klienta profils. Pēc tam atkārtojiet meklēšanu programmā, kas patiešām neizdevās, ne tikai čaulā, un pierakstiet saskarni no route -n get blakus rezultātam.

Lai atceltu izmaiņas, atvienojieties un atkārtojiet bāzes līnijas fiksēšanu. Ja ierobežotais bloks ir pazudis, klients ir sakārtojis pēc sevis. Ja bloks joprojām ir uzskaitīts pret saskarni, kuras vairs nav, stāvoklis ir novecojis, un notīrīšana kopā ar atkārtotu pieslēgšanos ir vismaigākais labojums, pirms kāds aizskar profilu.

Četras pārbaudes šādā secībā: vai kāds risinātāja bloks atbilst vārda garākajam sufiksam; vai šis bloks ir saistīts ar saskarni, ko uzstādīja tunelis; vai maršruts uz tā nosaukumu serveri izmanto tuneli; un vai atbildi atgriež sistēmas risinātājs, nevis dig. Pirmā neizdevusies pārbaude pasaka, vai mainīt DNS politiku, tuneļa maršrutus vai programmu. Ja visas četras iztur un vārds joprojām neizdodas, problēma ir virs DNS, un nākamais, kas jāapskata, ir viss, kas tā priekšā atbild uz 53. portu.