Nola aztertu zure Mac-ek VPN batean erabiltzen dituen DNS ebazleak

scutil --dns macOS-ek benetan aholkatzen duen ebazlearen konfigurazioa inprimatzen du, ezarpen-panel batean idatzi zenuen DNS zerbitzari bakarra baino. Irteera jendeak espero duena baino luzeagoa da, sistemak ebazle-bloke bereiziak gordetzen baititu bide lehenetsirako, esparruko interfazeetarako eta domeinuen araberako birbidalketarako. Irteeraren goiko blokea ez da derrigorrez kontsulta erantzuten duena. Izen pribatu bat bulegoan ebazten bada eta VPN-a igotzen den unean huts egiten badu, desdoitzea bat etortze-arauetan eta ibilbideetan dago, ez zerbitzariaren helbidean. Irakurri lehenengo ordena eta gero frogatu erantzuna benetako bilaketa batekin.

Irakurri blokeen ordena helbideen aurretik

Sarrera bakoitza resolver #N-ekin hasten da eta nameserver[0] zerrendatzen du, batzuetan if_index, flags lerro bat, reach, eta blokea lehenetsi soila ez denean, domain eta search domain zerrenda bat. Domeinurik gabeko 1. ebazlea da izen publikoak kudeatzen dituen lehenetsia. Bere banderetan Scoped daraman edozein if_index-ek izendatzen duen interfazera lotuta dago, eta Supplemental markatuta dagoen edozein haren azpian zerrendatutako domeinuei baino ez zaie aplikatzen.

Hautaketa atzizki-bat etortzea da. intranet.corp.example bezalako izen batentzat, macOS-ek domain sarrera bat datorren atzizkirik luzeena duen ebazlea nahiago du, beraz domain : corp.example duen bloke batek lehenetsia irabazten du irteeran oso behera egon arren. order-ek luzera bereko domeinuen arteko berdinketak hausten ditu. Lehen begirada batek gutxitan behar du gehiago: irteera osoa bloke bat hasieratik amaierara irakurri nahi duzunean, hasierako lerroak blokeen ordena ikasteko, eta iragazitako pasada bat blokeen goiburuak eremu-lerroen ondoan inprimatzen dituena. Esparruko blokeak beren goiburuaren azpian agertzen dira eta gaineko zerrendaren jarraipena dirudite, beraz eduki goiburu bat ikusmiran irteera aipatzen duzun bakoitzean.

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'

Lotu if_index tunel-interfazeari

Indize bat erabilgarria da haren atzean dagoen interfazea izendatu badezakezu. scutil --nwi-ek sistemak gordetzen duen sare-informazioa zerrendatzen du, interfaze nagusia eta irisgarritasuna barne, eta ifconfig -l-ek izenak ematen dizkizu, non utun0 eta utun9 bezero batek normalean sortzen dituen tunel-hautagaiak diren. Apple-k scutil --dns erabiltzen du bere azterketa-adibide gisa inplementazio-gidan, eta dokumentatzen du nola Network Extension-ek hautatutako domeinuak hautatutako ebazleetara bidera ditzakeen, eta horixe da esparruko bloke horiek agerian uzten duten mekanismoa.

Galdera erabakitzen duen egiaztapena da ea ebazlea tunelak instalatu zuen bidean dagoen:

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

route -n get-ek ebazle-sarrerarekin bat ez datozen atea eta interfazea itzultzen baditu, helbidea erabat zuzena izan daiteke eta hala ere iristezina. Enpresako azpisareak soilik daramatzan tunel zatituak haietatik kanpoko DNS zerbitzari batera bideratutako kontsultak botatzen ditu, eta hutsegitea denbora-muga gisa agertzen da, horregatik konfigurazio-irteerak garbi dirudi oraindik.

Galdetu sistemaren ebazleari, gero zerbitzariari

Hiru tresnak hiru galdera desberdini erantzuten diete, eta haiek nahasteak arlo honetako ondorio oker gehienak sortzen ditu. dscacheutil -q host -a name aplikazio arruntek erabiltzen duten sistema-ebazle beretik pasatzen da, beraz esparruko eta osagarrizko blokeak aplikatzen dira. Zerbitzari-argumenturik gabeko dig-ek /etc/resolv.conf irakurtzen du, eta hori ez da egia-iturria macOS-en esparruko ebazpenerako, eta domeinu bakoitzeko arauak erabat saltzen ditu. dig @address zerbitzari bakarrera iristen da eta ez dizu hautaketari buruz ezer esaten.

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

Lehen komandoak erantzuten duenean eta bigarrenak NXDOMAIN itzultzen duenean, bilatzen ari zinen zatiketa aurkitu duzu eta ez dago ezer hautsita. Lehena denbora-mugan amaitzen denean dig @10.20.0.53-ek erantzuten duen bitartean, ebazlea funtzionatzen du baina ez da iristezina tunelak aukeratutako bidean, beraz hurrengo urratsa route -n get da, ez DNS ezarpenak aldatzea. Eduki izen pribatuak tiketean edo partekatutako ohar batean itsasten duzun edozeren kanpo.

Irteerak ezin dizuna erakutsi

Geruza batzuk ebazle-zerrendaren gainean edo ondoan esertzen dira, eta bakoitzak kontsulta bat bidal dezake irteerak inoiz aipatzen ez duen tokira. DNS segurua gaituta duen nabigatzaile batek bere kanal zifratutik ebatzi dezake, beraz dscacheutil denbora-mugan amaitzen den bitartean kargatzen den orria ez da kontraesana. Segurtasun-softwareak instalatutako DNS proxi bat Network Extension hornitzaile gisa exekutatzen da eta berak birbidaltzen ditu kontsultak, eta scutil --dns-ek konfiguratu zena erakusten du, proxiak azkenean erabili zuen gorako helbidea ez. Bilaketa-domeinuek hirugarren tolestura gehitzen dute: kualifikatu gabeko izenari zerrendatutako atzizki bakoitza ordenan eransten zaio, beraz erantzun zuen blokea inoiz susmatu ez zenuen bat izan daiteke.

Erantzun zaharkituak baztertzeko gauzarik merkeena eta gehien baztertzen dena dira:

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

Garbiketa ondoren irteera aldatzen bada, egoera cachean zegoen eta aurreko irteerak jada existitzen ez zen tunel bat deskribatzen zuen. Aldatzen ez bada, konfigurazioa dena da, eta galdera ibilbideetara eta aplikazio-politikara pasatzen da.

Aurretik eta ondorenerako runbook labur bat

Harrapatu oinarri-lerro bat politikak onartzen duen tokietan soilik, eta eduki fitxategiak sinkronizatutako karpeta batetik kanpo. Beheko sekuentzia da cliente-makinetan exekutatzen dudana: harrapatu oinarri-lerroa, konektatu, harrapatu berriro, eta gero konparatu eta bilatu.

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

Irakurri aldea blokeka, ez lerreka. Tunel-interfazearen indizea eta atzizki pribatuaren domain sarrera daramatzan esparruko ebazle berri bat da espero den forma. Helbide publiko batera begira dagoen lehenetsitako ebazle berri bat da cliente-profilaren jabe denari planteatzea merezi duen aurkikuntza. Ondoren errepikatu bilaketa benetan huts egin zuen aplikazioaren barruan, ez bakarrik oskoletik, eta idatzi route -n get-eko interfazea emaitzaren ondoan.

Aldaketa bat desegiteko, deskonektatu eta errepikatu oinarri-lerroaren harrapaketa. Esparruko blokea desagertu bada, bezeroak bere buruaren atzetik garbitu du. Blokea jada existitzen ez den interfaze baten aurka zerrendatuta badago, egoera zaharkituta dago, eta garbiketa gehi berrekonexioa da ukitu beharreko konponbiderik leunena inork profila ukitu aurretik.

Lau egiaztapen, ordena honetan: ebazle-bloke batek izenaren atzizkirik luzeenarekin bat egiten duen, bloke hori tunelak instalatutako interfazera lotuta dagoen, haren izen-zerbitzarirako ibilbideak tunela erabiltzen duen, eta sistemaren ebazleak, eta ez dig-ek, erantzuna itzultzen duen. Huts egiten duen lehen egiaztapenak esaten dizu DNS politika, tunelaren ibilbideak edo aplikazioa aldatu behar dituzun. Laurak pasatzen badira eta izenak oraindik huts egiten badu, arazoa DNSaren gainean dago, eta hurrengo aztertu beharrekoa haren aurrean 53 portuan erantzuten duena da.