Ինչպես ստուգել DNS լուծիչները, որոնք ձեր Mac-ը օգտագործում է VPN-ում

scutil --dns տպում է լուծիչի այն կազմաձևը, որին macOS-ը իրականում դիմում է, ոչ թե այն միակ DNS սերվերը, որը դուք մուտքագրել էիք կարգավորումների վահանակում։ Ելքը ավելի երկար է, քան շատերն են սպասում, որովհետև համակարգը պահում է առանձին լուծիչ բլոկներ լռելյայն ուղու, սահմանափակ ինտերֆեյսների և տիրույթին բնորոշ փոխանցման համար։ Ելքի վերևի բլոկը պարտադիր չէ, որ հենց այն լինի, որը պատասխանում է հարցմանը։ Եթե մասնավոր անունը գրասենյակում լուծվում է և ձախողվում այն պահին, երբ VPN-ը բարձրանում է, անհամապատասխանությունը համապատասխանեցման կանոնների և երթուղիների մեջ է, ոչ թե սերվերի հասցեում։ Նախ կարդացեք հերթականությունը, ապա ապացուցեք պատասխանը իրական որոնմամբ։

Կարդացեք բլոկների հերթականությունը հասցեներից առաջ

Յուրաքանչյուր գրառում բացվում է resolver #N-ով և թվարկում է nameserver[0], երբեմն if_index, flags տող, reach, և երբ բլոկը սովորական լռելյայն չէ, domain և search domain ցանկ։ Առանց տիրույթի 1-ին լուծիչը լռելյայնն է, որը սպասարկում է հանրային անունները։ Ամեն ինչ, որ իր դրոշներում կրում է Scoped, կապված է այն ինտերֆեյսի հետ, որը նշում է if_index-ը, և Supplemental-ով նշված ամեն ինչ վերաբերում է միայն դրա տակ թվարկված տիրույթներին։

Ընտրությունը վերջածանցի համապատասխանեցումն է։ intranet.corp.example-ի նման անվան համար macOS-ը նախընտրում է այն լուծիչը, որի domain գրառումը ամենաերկար համընկնող վերջածանցն է, այնպես որ domain : corp.example ունեցող բլոկը հաղթում է լռելյայնին նույնիսկ ելքի շատ ներքևում լինելով։ order-ը լուծում է նույն երկարության տիրույթների միջև հավասարությունը։ Առաջին հայացքը հազվադեպ ավելի շատ բանի կարիք ունի՝ ամբողջ ելքը, երբ ուզում եք մեկ բլոկ կարդալ սկզբից մինչև վերջ, սկզբնական տողերը՝ բլոկների հերթականությունը սովորելու համար, և զտված անցում, որը տպում է բլոկների վերնագրերը դաշտերի տողերի կողքին։ Սահմանափակ բլոկները հայտնվում են իրենց սեփական վերնագրի տակ և կարդացվում են որպես իրենց վերևի ցանկի շարունակություն, ուստի ելքը մեջբերելիս վերնագիր միշտ պահեք աչքի առաջ։

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'

Համապատասխանեցրեք if_index-ը թունելի ինտերֆեյսին

Ինդեքսը օգտակար է միայն այն դեպքում, երբ կարող եք անվանել դրա հետևում գտնվող ինտերֆեյսը։ scutil --nwi-ը թվարկում է համակարգի պահած ցանցային տեղեկությունը, ներառյալ հիմնական ինտերֆեյսը և հասանելիությունը, իսկ ifconfig -l-ը տալիս է անունները, որտեղ utun0-ից utun9-ը թունելի թեկնածուներն են, որոնք սովորաբար ստեղծում է հաճախորդը։ Apple-ը scutil --dns-ը օգտագործում է որպես իր սեփական ստուգման օրինակ տեղակայման ուղեցույցում, և փաստաթղթավորում է, թե ինչպես Network Extension-ը կարող է ընտրված տիրույթները ուղղորդել ընտրված լուծիչներին, ինչը հենց այն մեխանիզմն է, որ բացահայտում են այդ սահմանափակ բլոկները։

Հարցը լուծող ստուգումն այն է՝ արդյոք լուծիչը գտնվում է այն ուղու վրա, որը տեղադրել է թունելը՝

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

Եթե route -n get-ը վերադարձնում է դարպաս և ինտերֆեյս, որոնք չեն համապատասխանում լուծիչի գրառմանը, հասցեն կարող է լիովին ճիշտ լինել և այնուամենայնիվ անհասանելի։ Միայն կորպորատիվ ենթացանցերը կրող բաժանված թունելը դեն է նետում դրանցից դուրս գտնվող DNS սերվերին ուղղված հարցումները, և ձախողումը երևում է որպես ժամանակի սպառում, այդ պատճառով կազմաձևի ելքը շարունակում է մաքուր թվալ։

Հարցրեք համակարգի լուծիչին, ապա սերվերին

Երեք գործիք պատասխանում են երեք տարբեր հարցերի, և դրանք շփոթելը ստեղծում է այս ոլորտի սխալ եզրակացությունների մեծ մասը։ dscacheutil -q host -a name-ը անցնում է նույն համակարգային լուծիչով, որն օգտագործում են սովորական հավելվածները, ուստի սահմանափակ և լրացուցիչ բլոկները գործում են։ Առանց սերվերի արգումենտի dig-ը կարդում է /etc/resolv.conf-ը, որը macOS-ում սահմանափակ լուծման ճշմարտության աղբյուրը չէ, և ամբողջությամբ բաց է թողնում տիրույթային կանոնները։ dig @address-ը հասնում է ճիշտ մեկ սերվերի և ոչինչ չի ասում ընտրության մասին։

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

Երբ առաջին հրամանը պատասխանում է, իսկ երկրորդը վերադարձնում է NXDOMAIN, դուք գտել եք ձեր փնտրած բաժանումը և ոչինչ կոտրված չէ։ Երբ առաջինը ժամանակային սահման է հասնում, մինչ dig @10.20.0.53-ը պատասխանում է, լուծիչը աշխատում է, բայց հասանելի չէ թունելի ընտրած ուղու վրա, ուստի հաջորդ քայլը route -n get-ն է, այլ ոչ DNS կարգավորումների խմբագրումը։ Մասնավոր անունները հեռու պահեք ամեն ինչից, ինչ կպցնում եք տոմսի կամ համօգտագործվող նշումի մեջ։

Ինչ չի կարող ցույց տալ ելքը

Մի քանի շերտ նստում են լուծիչների ցանկի վերևում կամ կողքին, և յուրաքանչյուրը կարող է հարցում ուղարկել մի տեղ, որը ելքը երբեք չի հիշատակում։ Անվտանգ DNS-ով զննարկիչը կարող է լուծել իր իսկ գաղտնագրված ուղիով, ուստի էջը, որը բեռնվում է, մինչ dscacheutil-ը ժամանակային սահման է հասնում, հակասություն չէ։ Անվտանգության ծրագրով տեղադրված DNS վստահված անձը աշխատում է որպես Network Extension մատակարար և ինքն է փոխանցում հարցումները, իսկ scutil --dns-ը ցույց է տալիս, թե ինչ է կարգավորվել, այլ ոչ այն վերին հոսքի հասցեն, որն ի վերջո օգտագործել է վստահված անձը։ Որոնման տիրույթներն ավելացնում են երրորդ ծալքը՝ ոչ որակավորված անվանը հերթով ավելացվում է թվարկված յուրաքանչյուր վերջածանց, ուստի պատասխանող բլոկը կարող է լինել մեկը, որի մասին երբեք չեք կասկածել։

Հնացած պատասխանները բացառելու ամենաէժան և ամենահաճախ բաց թողնված բանն են՝

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

Եթե մաքրումից հետո ելքը փոխվում է, վիճակը պահված էր քեշում, և նախորդ ելքը նկարագրում էր թունել, որն այլևս չկար։ Եթե չի փոխվում, կազմաձևը այնպիսին է, ինչպիսին կա, և հարցը տեղափոխվում է երթուղիներ և հավելվածային քաղաքականություն։

Կարճ ուղեցույց առաջ և հետո

Ելակետային գիծ վերցրեք միայն այնտեղ, որտեղ քաղաքականությունը թույլ է տալիս, և ֆայլերը պահեք ցանկացած համաժամեցված պանակից դուրս։ Ստորև բերված հաջորդականությունն այն է, ինչ ես գործարկում եմ հաճախորդական մեքենաներում՝ վերցնել ելակետը, միանալ, նորից վերցնել, ապա համեմատել և որոնել։

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

Տարբերությունը կարդացեք ըստ բլոկների, ոչ թե ըստ տողերի։ Սպասվող ձևը նոր սահմանափակ լուծիչն է, որը կրում է թունելի ինտերֆեյսի ինդեքսը և domain գրառում մասնավոր վերջածանցի համար։ Նոր լռելյայն լուծիչը, որը ցույց է տալիս հանրային հասցեի, այն հայտնաբերությունն է, որն արժե բարձրացնել հաճախորդի պրոֆիլի տիրոջ առջև։ Այնուհետև կրկնեք որոնումը հենց այն հավելվածի ներսում, որն իրականում ձախողվել է, ոչ միայն shell-ում, և արդյունքի կողքին գրեք route -n get-ից ստացված ինտերֆեյսը։

Փոփոխությունը հետարկելու համար անջատվեք և կրկնեք ելակետի վերցնումը։ Եթե սահմանափակ բլոկը անհետացել է, հաճախորդը մաքրել է իր հետևից։ Եթե բլոկը դեռ թվարկված է մի ինտերֆեյսի դիմաց, որն այլևս չկա, վիճակը հնացած է, և մաքրումը գումարած վերամիացումը ամենամեղմ ուղղումն է, նախքան որևէ մեկը կդիպչի պրոֆիլին։

Չորս ստուգում այս հերթականությամբ՝ արդյոք լուծիչի որևէ բլոկ համապատասխանում է անվան ամենաերկար վերջածանցին, արդյոք այդ բլոկը կապված է թունելի տեղադրած ինտերֆեյսին, արդյոք դրա անվան սերվեր տանող երթուղին օգտագործում է թունելը, և արդյոք պատասխանը վերադարձնում է համակարգի լուծիչը, այլ ոչ dig-ը։ Առաջին ձախողված ստուգումը ձեզ ասում է, թե DNS քաղաքականությունը, թունելի երթուղիները, թե հավելվածը փոխել։ Եթե բոլոր չորսն անցնեն, և անունը դեռ ձախողվի, խնդիրը DNS-ից վերև է, և հաջորդը, ինչ պետք է ստուգել, այն է, ինչ պատասխանում է 53 պորտին դրա առջևում։