Hoe jo de DNS-oplossers kontrolearje dy’t jo Mac op in VPN brûkt

scutil --dns prints de oplosserkonfiguraasje dy’t macOS echt rieplachtet, net de iene DNS-tsjinner dy’t jo yn in ynstellingspaniel typt hawwe. De útfier is langer as de measte minsken ferwachtsje, om’t it systeem aparte oplosserblokken hâldt foar it standertpaad, foar beheinde ynterfaces en foar domeinspeisifiko trochstjoeren. It blok boppe-oan de útfier is net needsaaklik it blok dat de fraach beantwurdet. As in priveenamme op kantoar oplost en mislearret op it stuit dat it VPN omheech komt, sit de misferhâlding yn ’e oerienkomstregels en rûtes, net yn it tsjinneradres. Lês earst de oarder en bewize dan it antwurd mei in echte syktocht.

Lês de blokoarder foar de adressen

Elk item begjint mei resolver #N en listet nameserver[0] op, soms if_index, in flags-rigel, reach en, as it blok net in gewoane standert is, in domain en in search domain-list. Oplosser nûmer 1 sûnder domein is de standert dy’t iepenbiere nammen behannelt. Alles wat Scoped yn syn flaggen draacht is bûn oan ’e ynterface dy’t if_index neamt, en alles wat mei Supplemental markearre is jildt allinnich foar de domeinen dy’t derûnder steane.

De kar is efterheaksel-oerienkomst. Foar in namme as intranet.corp.example ferkiest macOS de oplosser waans domain-item it langste oerienkommende efterheaksel is, dus in blok mei domain : corp.example wint fan ’e standert sels as it fier ûnderyn ’e útfier stiet. order brekt lykweardigens tusken domeinen fan deselde lingte. In earste each sjocht selden mear nedich as dit: de hiele útfier as jo ien blok fan begjin oant ein lêze wolle, de iepeningsrigels om ’e blokoarder te learen, en in filtere pass dy’t de blokkekoppen njonken de fjildrigels prints. Beheinde blokken ferskine ûnder har eigen kop en lêze as in fuortsetting fan ’e list derboppe, dus hâld in kop yn byld as jo de útfier sitearje.

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'

Keppelje if_index oan ’e tunnel-ynterface

In yndeks is allinnich nuttich as jo de ynterface derachter neame kinne. scutil --nwi listet de netwurkyndieling op dy’t it systeem hâldt, ynklusyf de primêre ynterface en berikberens, wylst ifconfig -l jo de nammen jout, wêr’t utun0 oant utun9 de tunnelkandidaten binne dy’t in klant normaal makket. Apple brûkt scutil --dns as syn eigen ynspeksjefoarbyld yn ’e ynsetgids, en dokumintearret hoe’t Network Extension selekteare domeinen nei selekteare oplossers liede kin, wat it meganisme is dat dy beheinde blokken bleatlegge.

De kontrôle dy’t de fraach beslist is oft de oplosser op it paad sit dat de tunnel ynstallearre hat:

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

As route -n get in poarte en ynterface weromjout dy’t net by it oplosseritem passe, kin it adres folslein korrekt wêze en dochs net berikber. In splitst tunnel dy’t allinnich de bedriuws-subnetten draacht, smyt fragen nei in DNS-tsjinner bûten dy subnetten fuort, en de flater docht him foar as in tiidferrin, dêrom bliuwt de konfiguraasje-útfier der skjin útsjen.

Freegje de systeemoplosser, dan de tsjinner

Trije ark beantwurdzje trije ferskillende fragen, en it trochinoar heljen fan harren bringt de measte ferkearde konklúzjes yn dit fjild fuort. dscacheutil -q host -a name giet troch deselde systeemoplosser dy’t gewoane applikaasjes brûke, dus beheinde en oanfoljende blokken jilde. dig sûnder tsjinnerargumint lêst /etc/resolv.conf, dat net de boarne fan wierheid is foar beheind oplossen op macOS, en it slacht de regels per domein hielendal oer. dig @address berikt presys ien tsjinner en seit neat oer de kar.

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

As it earste kommando antwurdet en it twadde NXDOMAIN weromjout, hawwe jo de splitsing fûn dy’t jo sochten en is neat stikken. As it earste tiidferrin krijt wylst dig @10.20.0.53 antwurdet, wurket de oplosser wol, mar is er net berikber op it paad dat de tunnel keas, dus de folgjende stap is route -n get en net in bewurking fan ’e DNS-ynstellingen. Hâld priveenammen bûten alles wat jo yn in ticket of in dielde notysje plakke.

Wat de útfier jo net sjen litte kin

Ferskate lagen sitte boppe of njonken de oplosserlist, en elk kin in fraach earne hinne stjoere dat de útfier nea neamt. In browser mei feilich DNS oan kin oer syn eigen fersifere kanaal oplosse, dus in side dy’t lade wylst dscacheutil tiidferrin krijget is gjin tsjinstelling. In DNS-proxy dy’t troch befeiligingssoftware ynstalleare is, rint as Network Extension-oanbieder en stjoert fragen sels troch, en scutil --dns lit sjen wat konfigurearre is, net it boppestreamadres dat de proxy úteinlik brûkte. Sikoardomeinen foegje in tredde ploaits ta: oan in net-kwalifisearre namme wurdt elk listet efterheaksel yn oarder taheakke, dus it blok dat antwurde kin ien wêze dy’t jo nea fermoede hawwe.

Ferâldere antwurden binne it goedkeapste om út te sluten en it meast oersleine:

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

As de útfier nei it leegjen feroaret, wie de steat yn ’e buffer en beskreau de eardere útfier in tunnel dy’t net mear bestie. As er net feroaret, is de konfiguraasje sa’t er is, en ferhúzet de fraach nei rûtes en nei applikaasjebelied.

In koart draaiboek foar foar en nei

Meitsje allinnich in basisline op wêr’t belied it tasteit, en hâld de bestannen bûten elke syngronisearre map. De folchoarder hjirûnder is wat ik op klantmasines rin: meitsje de basisline, ferbin, meitsje wer, fergelykje dan en sykje op.

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

Lês it ferskil per blok ynstee fan per rigel. In nij beheind oplosser dat de tunnel-ynterface-yndeks en in domain-item foar it privee efterheaksel draacht is de ferwachte foarm. In nije standertoplosser dy’t nei in iepenbier adres wiist is in befinining dy’t it wurdich is om op te bringen by wa’t it klantprofyl besit. Werhelje dan de syktocht yn ’e applikaasje dy’t echt mislearre, net allinnich yn ’e skelp, en notearje de ynterface út route -n get njonken it resultaat.

Om in feroaring werom te draaien, ferbrekke en werhelje it opmeitsjen fan ’e basisline. As it beheinde blok fuort is, hat de klant efter himsels opromme. As it blok noch listet is tsjin in ynterface dy’t net mear bestiet, is de steat ferâldere, en in leegjen plus in werferbining is de sêftste reparaasje foar’t immen it profyl oanrekket.

Fjouwer kontrôles yn dizze oarder: past in oplosserblok by it langste efterheaksel fan ’e namme, is dat blok bûn oan ’e ynterface dy’t de tunnel ynstallearre, brûkt de rûte nei syn nammentsjinner de tunnel, en jout de systeemoplosser, net dig, it antwurd werom. De earste kontrôle dy’t mislearret fertelt jo oft jo it DNS-belied, de tunnelrûtes of de applikaasje feroarje moatte. As alle fjouwer slagje en de namme dochs mislearret, sit it probleem boppe DNS, en it folgjende dat besjoen wurde moat is alles wat foar him port 53 beantwurdet.