VPN-iniz üç DNS serverini göndərir: hansı cavab verir?
Əlavə qeydlər ehtiyat variant, domain üzrə marşrut və ya fiziki bağlantıdan qalan iz ola bilər. Siyahını sızma adlandırmazdan əvvəl hər birini öz əhatə dairəsinə bağlayın.
Qoşulduqdan sonra parametrlər səhifəsini açın və üç DNS ünvanı görünür; audit sualı bunlardan hansının son sorğunuzu idarə etdiyidir. Təkbaşına say heç nəyə cavab vermir, çünki müştəri göndərişi, fiziki interfeys və hər domain üçün siyasət eyni görünüşə yazır. Bu qeydlər fərqli əhatə dairələri daşıyır və cavab verənin kim olduğunu mövqe deyil, məhz əhatə dairəsi müəyyən edir. Mənbələri ayırmaqla başlayın, sonra sizin üçün vacib olan adı daşıyan mənbəyi sınayın.
Siyahı niyə profilinizdən uzundur
VPN müştərisi tunel bağlantısı üçün resolver ünvanlarını göndərir, əməliyyat sistemi isə onları fiziki interfeysin əvvəlcədən saxladığı ünvanların yanında saxlayır. Marşrutlaşdırıcı, korporativ DHCP icarəsi, ikinci VPN və hər domain üçün siyasət hər biri öz qeydini əlavə edir. Səhifədəki üç ünvan buna görə bir iş üçün üç namizəd deyil, üç əhatə dairəsi mənasına gələ bilər. Sayı sızma sübutu kimi oxumaq bu auditin ilk səhvidir.
Bir interfeys daxilində müştəri serverlərini sıra ilə sınayır, ona görə sıralanmış siyahı mənasız deyil. Növbə olmayan şey birləşdirilmiş görünüşdür: profilin, fiziki bağlantının və domain qaydalarının qeydləri vahid reytinq olmadan yanaşı durur. Bu fərq nəyi sınayacağınızı müəyyən edir: sıra bir əhatə dairəsi daxilində davranışı izah edir, əhatə dairəsi isə qalan hər şeyi.
Şifrələnmiş DNS mənzərəni tətbiqin içindən pozur. Öz DNS-over-HTTPS resolveri olan brauzer və ya söhbət müştərisi sorğuları əməliyyat sistemi siyahısından tamamilə yan keçərək göndərir, ona görə parametrlər səhifəsindəki ünvanlar tətbiqin heç vaxt yaratmadığı trafiki təsvir edir. Adı səhv çıxdığına görə profili günahlandırmazdan əvvəl tətbiqin öz resolver parametrini yoxlayın.
Hər üç yoxlamanın verdiyi cavab
Hər mənbə öz izini başqa yerdə qoyur və heç bir tək əmr hamısını göstərmir. Parametrlər səhifəsinin yanında saxlanmağa dəyən xəritə budur:
| Entry source | Where it is visible | What it proves |
|---|---|---|
| Tunnel profile | Link-scoped DNS on the tunnel device | Which servers the VPN asked you to use, not which one answered |
| Per-domain policy | Suffix list or routing domains | Which names are steered to a particular resolver |
| Physical link | DNS on the LAN interface | Whether a second scope still exists outside the tunnel |
| Application resolver | App settings, absent from the OS list | Whether the system list was consulted at all |
systemd-resolved istifadə edən sistemdə resolvectl status səlahiyyətlidir, çünki DNS-i marşrutlaşdırma domainləri ilə birlikdə hər bağlantı üzrə bildirir. macOS scutil --dns vasitəsilə cavab verir və əhatəli resolverləri sınanma sırası ilə sadalayır. Windows iki yarığı ayırır: hər interfeys üzrə serverlər üçün Get-DnsClientServerAddress və suffiks qaydaları üçün Get-DnsClientNrptPolicy. Faktiki istifadə olunan resolverə aid əmri işə salın, çünki konteyner mühiti və masaüstü resolveri olan maşında birdən çoxu quraşdırılmış ola bilər.
Zonanıza cavab verə bilməyən ehtiyat resolver
İkinci qeyd adətən mövcudluq üçün oradadır və mövcudluq yalnız ehtiyat adları bildikdə işləyir. Ümumi resolverdən daxili host adı soruşun və o, NXDOMAIN qaytarır, yaxud sizinlə heç əlaqəsi olmayan axtarış domainindən vəhşi kart cavabı verir. Heç kimin yoxlamadığı ehtiyat keçid isə məhz ona ehtiyac duyulan anda kəsinti yaradır.
Split DNS bunun qarşısını almaq üçün mövcuddur: şirkət suffiksləri zonanı saxlayan resolverə gedir, ümumi adlar isə standart yolda qalır. Dizayn düzgündür və o, suffiks siyahısının tam olmasından asılıdır. Microsoft bunun Windows-da işləməsini təmin edən hər suffiks üzrə resolver siyasətini sənədləşdirir və eyni fikir systemd-resolved-də marşrutlaşdırma domainləri, macOS-da isə əhatəli resolverlər kimi görünür.
Ehtiyatın cavab verə biləcəyi zonaları siyasətdəki suffikslərlə müqayisə edin. Bu müqayisə istifadəçi tunel dəyişikliyindən sonra bir daxili saytın həllini dayandırdığını bildirməzdən əvvəl boşluğu tapır.
Siyasətin içindən soruşun, ondan yan keçməyin
Əməliyyat sistemi resolveri vasitəsilə soruşun, çünki serverə birbaşa sorğu siyasəti yan keçir və yalnız həmin serverin nə deyəcəyini bildirir. İki cavab arasındakı fərq bütün məsələnin özüdür:
resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53
Sistem sorğusu şəxsi ünvan qaytarır, birbaşa sorğu isə NXDOMAIN qaytarırsa, siyasət işləyir və zəif nöqtə ehtiyatdır. Əgər hər ikisi eyni ümumi cavabı qaytarırsa, ad nəzərdə tutduğunuz əhatə dairəsindən kənarda həll olunur və baxmalı olduğunuz yer suffiks siyahısıdır. Hər iki çıxışı saxlayın, çünki resolver mübahisəsi parametrlər səhifəsinin ekran görüntüsündən çox iki sətirlə daha tez həll olunur.
Sonra uğursuzluq yolunu sınayın, çünki heç kimin yoxlamadığı ehtiyat bir fərziyyədir. Üstünlük verilən resolveri bir sorğu üçün qara dəliyə çevirin və hansı ünvanın qayıtdığına baxın:
ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32
Sorğu bitən kimi həmin marşrutu silin, əks halda növbəti şəxs bir sirr miras alır. Əgər daxili adlar o pəncərədə hələ də həll olunursa, onlara nəzərdə tutulan əhatə dairəsindən kənarda bir şey cavab verib. Əgər əvəzində vaxt aşımı olursa, ehtiyat yoxdur və ya düzgün əhatələnib və resolverin öz jurnalı bunlardan hansının olduğunu deyir.
Qərar verin: saxla, əhatələ və ya sil
İkinci resolveri o, ehtiyac duyduğunuz ad məkanına cavab verdikdə və profil altında əlçatan qaldıqda saxlayın. Onu bir suffiks görəcəksə və başqa heç nə görməyəcəksə əhatələyin, nə əhatə dairəsi, nə sənədləşdirilmiş məqsədi olduqda isə silin. Heç bir iş görməyən qeyd faydasız gələcək sızmadır və satıcının standartı məqsəd deyil.
Nəticəni dörd sütun kimi qeyd edin: suffiks, resolver, interfeys və sahib. Bu sətir növbəti audit sualına istənilən ekran görüntüsündən tez cavab verir və siyahını səssizcə yenidən sıralayan müştəri yeniləməsindən sağ çıxır.