Kiel kontroli la DNS-solvilojn, kiujn via Mac uzas ĉe VPN

scutil --dns presas la solvilan agordon, kiun macOS efektive konsultas, ne la ununuran DNS-servilon, kiun vi tajpis en agordan panelon. La eligo estas pli longa ol plej multaj homoj atendas, ĉar la sistemo tenas apartajn solvilajn blokojn por la defaŭlta vojo, por skopaj interfacoj kaj por domajno-specifa plusendado. La bloko supre en la eligo ne nepre estas tiu, kiu respondas la demandon. Se privata nomo solviĝas en la oficejo kaj malsukcesas en la momento, kiam la VPN ekfunkcias, la miskongruo kuŝas en la kongruaj reguloj kaj la vojoj, ne en la servila adreso. Legu unue la ordon, poste pruvu la respondon per reala serĉo.

Legu la blokan ordon antaŭ la adresoj

Ĉiu ero malfermiĝas per resolver #N kaj listigas nameserver[0], foje if_index, linion flags, reach kaj, kiam la bloko ne estas simpla defaŭlto, domain kaj liston search domain. Solvilo numero 1 sen domajno estas la defaŭlto, kiu traktas publikajn nomojn. Ĉio, kio portas Scoped en siaj flagoj, estas ligita al la interfaco nomita de if_index, kaj ĉio markita per Supplemental validas nur por la domajnoj listigitaj sub ĝi.

La elekto estas sufiksa kongruo. Por nomo kiel intranet.corp.example, macOS preferas la solvilon, kies ero domain estas la plej longa kongrua sufikso, do bloko kun domain : corp.example venkas la defaŭlton eĉ kiam ĝi staras profunde en la eligo. order solvas egalecojn inter domajnoj de la sama longo. Unua rigardo malofte bezonas pli: la tutan eligon, kiam vi volas legi unu blokon de komenco ĝis fino, la unuajn liniojn por lerni la blokan ordon, kaj filtritan trairon, kiu presas la blokajn kapojn apud la kampaj linioj. Skopaj blokoj aperas sub sia propra titolo kaj legeblas kiel daŭrigo de la listo super ili, do tenu titolon en la vido, kiam ajn vi citas la eligon.

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'

Parigu if_index al la tunela interfaco

Indekso utilas nur se vi povas nomi la interfacon malantaŭ ĝi. scutil --nwi listigas la retan informon, kiun la sistemo tenas, inkluzive de la ĉefa interfaco kaj atingeblo, dum ifconfig -l donas al vi la nomojn, kie utun0 ĝis utun9 estas la tunelaj kandidatoj, kiujn kliento kutime kreas. Apple uzas scutil --dns kiel sian propran kontrolan ekzemplon en la enkonduka gvidilo, kaj dokumentas, kiel Network Extension povas direkti elektitajn domajnojn al elektitaj solviloj, kio estas la mekanismo, kiun tiuj skopaj blokoj malkaŝas.

La kontrolo, kiu solvas la demandon, estas ĉu la solvilo sidas sur la vojo, kiun la tunelo instalis:

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

Se route -n get redonas pordegon kaj interfacon, kiuj ne kongruas kun la solvila ero, la adreso povas esti tute ĝusta kaj tamen neatingebla. Dividita tunelo, kiu portas nur la entreprenajn subretojn, forĵetas demandojn direktitajn al DNS-servilo ekster ili, kaj la malsukceso aperas kiel tempolimo, tial la agorda eligo daŭre aspektas pura.

Demandu la sistem-solvilon, poste la servilon

Tri iloj respondas tri malsamajn demandojn, kaj ilia konfuzado produktas la plej multajn malĝustajn konkludojn en ĉi tiu kampo. dscacheutil -q host -a name pasas tra la sama sistem-solvilo, kiun uzas ordinaraj aplikaĵoj, do skopaj kaj plenaj blokoj validas. dig sen servila argumento legas /etc/resolv.conf, kio ne estas la fonto de la vero por skopa solvado ĉe macOS, kaj ĝi tute preterlasas la regulojn por ĉiu domajno. dig @address atingas ekzakte unu servilon kaj diras nenion pri elekto.

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

Kiam la unua komando respondas kaj la dua redonas NXDOMAIN, vi trovis la dividon, kiun vi serĉis, kaj nenio estas rompita. Kiam la unua finiĝas per tempolimo dum dig @10.20.0.53 respondas, la solvilo funkcias sed ne estas atingebla sur la vojo, kiun la tunelo elektis, do la sekva paŝo estas route -n get anstataŭ ŝanĝo de la DNS-agordoj. Tenu privatajn nomojn ekster ĉio, kion vi algluas en bileton aŭ komunan noton.

Kion la eligo ne povas montri al vi

Pluraj tavoloj sidas super aŭ apud la solvila listo, kaj ĉiu povas sendi demandon ie, kion la eligo neniam mencias. Retumilo kun ŝaltita sekura DNS povas solvi tra sia propra ĉifrita kanalo, do paĝo, kiu ŝarĝiĝas dum dscacheutil finiĝas per tempolimo, ne estas kontraŭdiro. DNS-prokurilo instalita de sekureca programaro funkcias kiel Network Extension-provizanto kaj mem plusendas demandojn, kaj scutil --dns montras, kio estis agordita, ne la supran adreson, kiun la prokurilo finfine uzis. Serĉaj domajnoj aldonas trian faldon: al nekvalifikita nomo aldoniĝas ĉiu listigita sufikso laŭ ordo, do la bloko, kiu respondis, povas esti tiu, kiun vi neniam suspektis.

Malnovaj respondoj estas la plej malmultekosta afero por ekskludi kaj la plej ofte preterlasata:

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

Se la eligo ŝanĝiĝas post la malplenigo, la stato estis kaŝmemorigita kaj la pli frua eligo priskribis tunelon, kiu ne plu ekzistis. Se ĝi ne ŝanĝiĝas, la agordo estas tia, kia ĝi estas, kaj la demando transiras al vojoj kaj al aplikaĵa politiko.

Mallonga manlibro por antaŭ kaj post

Kaptu bazlinion nur tie, kie la politiko permesas, kaj tenu la dosierojn ekster iu ajn sinkronigita dosierujo. La sekvenco sube estas tio, kion mi rulas sur klientaj maŝinoj: kaptu la bazlinion, konektiĝu, kaptu denove, poste komparu kaj serĉu.

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

Legu la diferencon laŭ blokoj anstataŭ laŭ linioj. Nova skopa solvilo portanta la indekson de la tunela interfaco kaj eron domain por la privata sufikso estas la atendata formo. Nova defaŭlta solvilo direktanta al publika adreso estas trovajo inda prezenti al tiu, kiu posedas la klientan profilon. Poste ripetu la serĉon ene de la aplikaĵo, kiu efektive malsukcesis, ne nur en la ŝelo, kaj notu la interfacon el route -n get apud la rezulto.

Por malfari ŝanĝon, malkonektiĝu kaj ripetu la bazlinian kapton. Se la skopa bloko malaperis, la kliento purigis post si. Se la bloko ankoraŭ estas listigita kontraŭ interfaco, kiu ne plu ekzistas, la stato estas malnova, kaj malplenigo plus rekonekto estas la plej milda ripeto, antaŭ ol iu tuŝos la profilon.

Kvar kontroloj en ĉi tiu ordo: ĉu iu solvila bloko kongruas kun la plej longa sufikso de la nomo; ĉu tiu bloko estas ligita al la interfaco, kiun la tunelo instalis; ĉu la vojo al ĝia nomservilo uzas la tunnelon; kaj ĉu la sistem-solvilo, ne dig, redonas la respondon. La unua kontrolo, kiu malsukcesas, diras al vi, ĉu ŝanĝi la DNS-politikon, la tunelajn vojojn aŭ la aplikaĵon. Se ĉiuj kvar pasas kaj la nomo ankoraŭ malsukcesas, la problemo sidas super DNS, kaj la sekva afero kontrolenda estas ĉio, kio respondas al pordo 53 antaŭ ĝi.