તમારો Mac VPN પર કયા DNS રિઝોલ્વર વાપરે છે તે કેવી રીતે તપાસવું

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 જવાબ આપે છે, ત્યારે રિઝોલ્વર કામ કરે છે પણ ટનલે પસંદ કરેલા પાથ પર પહોંચી શકાય તેવું નથી, તેથી આગળનું પગલું DNS સેટિંગ્સમાં ફેરફાર નહીં પણ route -n get છે. ખાનગી નામોને ટિકિટ કે શેર કરેલી નોંધમાં પેસ્ટ કરો તે કોઈપણ વસ્તુની બહાર રાખો.

આઉટપુટ તમને શું બતાવી શકતું નથી

રિઝોલ્વર યાદીની ઉપર કે બાજુમાં ઘણા સ્તર બેસે છે, અને દરેક ક્વેરીને એવી જગ્યાએ મોકલી શકે છે જે આઉટપુટ કદી ઉલ્લેખ કરતું નથી. સુરક્ષિત 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 એન્ટ્રી ધરાવતો નવો સ્કોપ્ડ રિઝોલ્વર એ અપેક્ષિત આકાર છે. જાહેર સરનામા તરફ ઇશારો કરતો નવો ડિફોલ્ટ રિઝોલ્વર એ એવી શોધ છે જે ક્લાયન્ટ પ્રોફાઇલનો માલિક હોય તેની સમક્ષ મૂકવા યોગ્ય છે. પછી લુકઅપ ખરેખર નિષ્ફળ ગયેલી એપ્લિકેશનની અંદર પુનરાવર્તિત કરો, ફક્ત શેલમાં નહીં, અને પરિણામની બાજુમાં route -n get નું ઇન્ટરફેસ નોંધો.

ફેરફાર રદ કરવા માટે ડિસ્કનેક્ટ કરો અને બેઝલાઇન કેપ્ચર પુનરાવર્તિત કરો. જો સ્કોપ્ડ બ્લોક ગયો હોય, તો ક્લાયન્ટે પોતાની પાછળ સફાઈ કરી છે. જો બ્લોક હજી એવા ઇન્ટરફેસ સામે સૂચિબદ્ધ હોય જે હવે અસ્તિત્વમાં નથી, સ્થિતિ જૂની છે, અને કોઈ પ્રોફાઇલને સ્પર્શે તે પહેલાં ફ્લશ વત્તા પુનઃકનેક્શન એ સૌથી નરમ સુધારો છે.

આ ક્રમમાં ચાર તપાસ: કોઈ રિઝોલ્વર બ્લોક નામના સૌથી લાંબા પ્રત્યય સાથે મેળ ખાય છે કે નહીં; તે બ્લોક ટનલે સ્થાપિત કરેલા ઇન્ટરફેસ સાથે બંધાયેલો છે કે નહીં; તેના નામ સર્વર તરફનો રૂટ ટનલ વાપરે છે કે નહીં; અને સિસ્ટમ રિઝોલ્વર, dig નહીં, જવાબ પરત કરે છે કે નહીં. પ્રથમ નિષ્ફળ તપાસ તમને કહે છે કે DNS નીતિ, ટનલ રૂટ કે એપ્લિકેશન બદલવી છે. જો ચારેય પાસ થાય અને નામ હજી નિષ્ફળ જાય, તો સમસ્યા DNSની ઉપર છે, અને આગળ તપાસવાનું એ છે જે તેની સામે પોર્ટ 53 પર જવાબ આપે છે.