Mac-ınızın VPN-də istifadə etdiyi DNS həlledicilərini necə yoxlamaq olar

scutil --dns macOS-un həqiqətən müraciət etdiyi həlledici konfiqurasiyasını çap edir, parametrlər panelinə yazdığınız tək DNS serverini deyil. Çıxış çoxlarının gözlədiyindən uzundur, çünki sistem defolt yol, əhatəli interfeyslər və domenə xas yönləndirmə üçün ayrı-ayrı həlledici blokları saxlayır. Çıxışın başındakı blok sorğuya cavab verən blok olmaya bilər. Şəxsi ad ofisdə həll olunub VPN qalxdığı anda uğursuz olursa, uyğunsuzluq uyğunlaşdırma qaydalarında və marşrutlarda, server ünvanında deyil. Əvvəlcə sıranı oxuyun, sonra cavabı real axtarışla sübut edin.

Ünvanlardan əvvəl blok sırasını oxuyun

Hər giriş resolver #N ilə açılır və nameserver[0], bəzən if_index, flags sətri, reach, blok adi defolt olmadıqda isə domain və search domain siyahısını göstərir. Domeni olmayan 1 nömrəli həlledici açıq adlarla işləyən defoltdur. Bayraqlarında Scoped daşıyan hər şey if_index ilə adlandırılan interfeysə bağlıdır və Supplemental ilə işarələnən hər şey yalnız onun altında sadalanan domenlərə aiddir.

Seçim şəkilçi uyğunlaşdırmasıdır. intranet.corp.example kimi ad üçün macOS domain girişi ən uzun uyğun şəkilçi olan həllediciyə üstünlük verir, yəni domain : corp.example olan blok çıxışın çox aşağısında olsa belə defoltu üstələyir. order eyni uzunluqlu domenlər arasında bərabərliyi həll edir. İlk baxış nadir hallarda bundan çoxunu tələb edir: bir bloku başdan sona oxumaq istəyəndə bütün çıxış, blok sırasını öyrənmək üçün ilk sətirlər və blok başlıqlarını sahə sətirlərinin yanında çap edən filtrlənmiş keçid. Əhatəli bloklar öz başlığı altında görünür və yuxarıdakı siyahının davamı kimi oxunur, ona görə çıxışdan sitat gətirəndə həmişə başlığı göz önündə saxlayın.

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-i tunel interfeysi ilə uyğunlaşdırın

İndeks yalnız arxasındakı interfeysi adlandıra bildiyiniz halda faydalıdır. scutil --nwi sistemin saxladığı şəbəkə məlumatını, o cümlədən əsas interfeysi və əlçatanlığı göstərir, ifconfig -l isə sizə adları verir, burada utun0 -dən utun9 -a qədər müştərinin adətən yaratdığı tunel namizədləridir. Apple öz yoxlama nümunəsi kimi scutil --dns istifadə edir — rəsmi yayımlama bələdçisi bunu göstərir və Network Extension-un seçilmiş domenləri seçilmiş həlledicilərə necə yönləndirə biləcəyini sənədləşdirir; əhatəli blokların açdığı mexanizm elə budur.

Məsələni həll edən yoxlama həlledicinin tunelin qurduğu yolda olub-olmadığıdır:

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

route -n get həlledici girişinə uyğun gəlməyən şlüz və interfeys qaytarırsa, ünvan tamamilə düzgün ola bilər və yenə də əlçatmaz qalar. Yalnız korporativ alt şəbəkələri daşıyan bölünmüş tunel onlardan kənardakı DNS serverinə yönələn sorğuları atır və nasazlıq fasilə kimi üzə çıxır, ona görə konfiqurasiya çıxışı həmişə təmiz görünür.

Əvvəl sistem həlledicisindən, sonra serverdən soruşun

Üç alət üç fərqli suala cavab verir və onları qarışdırmaq bu sahədə səhv nəticələrin çoxunu yaradır. dscacheutil -q host -a name adi tətbiqlərin istifadə etdiyi sistem həlledicisindən keçir, ona görə əhatəli və əlavə bloklar tətbiq olunur. Server arqumenti olmayan dig /etc/resolv.conf faylını oxuyur, bu isə macOS-da əhatəli həlletmə üçün həqiqət mənbəyi deyil və domen üzrə qaydaları tamamilə atlayır. dig @address dəqiq bir serverə çatır və seçim barədə heç nə demir.

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

Birinci əmr cavab verib ikincisi NXDOMAIN qaytaranda, axtardığınız bölünməni tapmısınız və heç nə pozulmayıb. Birinci fasilə ilə bitəndə, dig @10.20.0.53 isə cavab verəndə, həlledici işləyir, amma tunelin seçdiyi yolda əlçatan deyil, ona görə növbəti addım DNS parametrlərini düzəltmək deyil, route -n get istifadə etməkdir. Şəxsi adları biletə və ya ortaq qeydə yapışdırdığınız heç bir şeyin içinə salmayın.

Çıxışın sizə göstərə bilmədikləri

Həlledici siyahısının üstündə və ya yanında bir neçə qat durur və hər biri sorğunu çıxışın heç vaxt xatırlatmadığı yerə göndərə bilər. Təhlükəsiz DNS aktiv olan brauzer öz şifrələnmiş kanalı ilə həll edə bilər, ona görə dscacheutil fasiləyə düşərkən yüklənən səhifə ziddiyyət deyil. Təhlükəsizlik proqramının quraşdırdığı DNS proksisi Network Extension təminatçısı kimi işləyir və sorğuları özü yönləndirir, scutil --dns isə konfiqurasiya olunanı göstərir, proksisin axırda istifadə etdiyi yuxarı ünvanı deyil. Axtarış domenləri üçüncü bir qırış əlavə edir: uyğunsuz ada sadalanan hər şəkilçi sıra ilə əlavə olunur, ona görə cavab verən blok heç şübhələnmədiyiniz biri ola bilər.

Köhnə cavablar istisna etmək üçün ən ucuz və ən çox atlanan şeydir:

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

Təmizləmədən sonra çıxış dəyişirsə, vəziyyət keşlənmişdi və əvvəlki çıxış artıq mövcud olmayan tuneli təsvir edirdi. Dəyişmirsə, konfiqurasiya nədirsə odur və sual marşrutlara və tətbiq siyasətinə keçir.

Əvvəl və sonra üçün qısa təlimat

Baza xəttini yalnız siyasətin icazə verdiyi yerdə götürün və faylları hər hansı sinxronlaşdırılan qovluqdan kənarda saxlayın. Aşağıdakı ardıcıllıq müştəri maşınlarında işlətdiyim addımlardır: baza xəttini götür, qoşul, yenidən götür, sonra fərqi çıxar və axtar.

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

Fərqi sətirlə deyil, blokla oxuyun. Tunel interfeys indeksini və şəxsi şəkilçi üçün domain girişini daşıyan yeni əhatəli həlledici gözlənilən formadır. Açıq ünvana baxan yeni defolt həlledici müştəri profilinin sahibinə çatdırılmağa dəyər bir tapıntıdır. Sonra axtarışı yalnız qabıqda deyil, həqiqətən uğursuz olan tətbiqin içində təkrarlayın və nəticənin yanında route -n get -dən interfeysi qeyd edin.

Dəyişikliyi geri qaytarmaq üçün əlaqəni kəsin və baza xəttinin götürülməsini təkrarlayın. Əhatəli blok yoxdursa, müştəri öz arxasınca təmizləyib. Blok hələ də mövcud olmayan interfeysə qarşı sadalanırsa, vəziyyət köhnəlib, və kimsə profilə toxunmazdan əvvəl təmizləmə üstəgəl yenidən qoşulma ən yumşaq düzəlişdir.

Bu sıra ilə dörd yoxlama: hər hansı həlledici bloku adın ən uzun şəkilçisinə uyğun gəlirmi; həmin blok tunelin qurduğu interfeysə bağlıdırmı; onun ad serverinə gedən marşrut tuneldən istifadə edirmi; və cavabı dig deyil, sistem həlledicisi qaytarırmı. Uğursuz olan ilk yoxlama DNS siyasətini, tunel marşrutlarını, yoxsa tətbiqi dəyişməli olduğunuzu deyir. Dördü də keçib ad yenə uğursuz olursa, problem DNS-in üstündədir və növbəti baxılacaq şey onun qarşısında 53 portuna cavab verən hər şeydir.