VPN DNS hər sorğunu ələ keçirir: NetworkManager-də dns-priority-ni tənzimləyin

Ofis VPN-inə qoşulun və birdən bütün ad sorğuları korporativ resolverə gedir. Ümumi adlar yenə də həll olunur, ona görə yerli printer adı uğursuz olana və ya split-horizon qeydi ofis ünvanını qaytarana qədər heç nə pozulmuş görünmür. Bəzi Fedora qurğularında əksi olur: tunel qalxdıqdan sonra da ISP resolveri cavab verməyə davam edir. Hər ikisi bir sualdır — bu sorğu hansı resolverə aiddir — və NetworkManager sistemlərində cavab hər bağlantının DNS xassələrində yaşayır.

İki bağlantı, bir qalib resolver

Hər bağlantı DNS prioriteti elan edir. Adi bağlantılar standart olaraq 50, VPN bağlantıları isə 0 götürür və aşağı dəyər qazanır. Bu standart VPN bağlantısının iddia etdiyi hər domen üçün simli əlaqəni səssizcə üstələməsinin səbəbidir: sıfır əllini heç kim seçmədən üstələyir.

Prioritet namizədləri sıralayır. Qalibin nədən sorğu alacağını məhdudlaşdırmır. Axtarış domeni olmayan VPN bağlantısı hər şeyi iddia edir, ona görə onu üstün tutmaq ümumi sorğuları da tunelə, split-tunel dizaynında isə korporativ resolverin yönləndirdiyi yerə göndərir.

Prioritet sıranı, axtarış siyahısı sahibliyi müəyyən edir

nmcli -f connection.id,ipv4.dns,ipv4.dns-search,ipv4.dns-priority con show "Corp VPN"
resolvectl status
readlink -f /etc/resolv.conf

Axtarış siyahısı sahiblik bəyanatıdır. corp.example kimi çılpaq domen axtarış şəkilçisi və marşrut domeni olur. Yalnız marşrut forması ~corp.example həmin şəkilçi altındakı sorğuları domeni qısa adlara əlavə etmədən bu bağlantıya göndərir. O tilda «bu serverdən soruş» ilə «bu serverdən soruş və yazmağımı bitir» arasındakı fərqdir.

Hər iki formanı istifadəçilər qısa host adları yazanda və qeydlər tam kvalifikasiyalı adlarla da ünvanlandıqda istifadə edin. Yalnız marşrut formasını isə resolverin çılpaq adı tamamlama qaydasını dəyişmədən bölgü istədikdə istifadə edin.

Sonra üstünlüyü açıq edin və yenidən aktivləşdirin:

nmcli con modify "Corp VPN" ipv4.dns-priority -100
nmcli con modify "Corp VPN" ipv6.dns-priority -100
nmcli con modify "Corp VPN" ipv4.dns-search "~corp.example,corp.example"
nmcli con up "Corp VPN"

Mənfi prioritet «bu bağlantını üstün tut» deməyin sənədləşdirilmiş yoludur və hər iki ünvan ailəsini birlikdə təyin etmək IPv6 bağlantısı olan hostda davranışı ardıcıl saxlayır. Xassəni bağlantını yenidən aktivləşdirmədən dəyişmək hazırda işləyən heç nəyi dəyişmir, buna görə ardıcıllıq açıq bir up əmri ilə bitir.

Bölgünü systemd-resolved saxlasın

Standart dnsmasq plaqini sorğuları bir yerli resolverə yığır, ona görə hər keçid üzrə ayrılıq qaba qalır. systemd-resolved bölgünü hər keçid üzrə göstərir və resolvectl query cavab verən keçidin adını çəkir.

systemctl enable --now systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
systemctl restart systemd-resolved NetworkManager
resolvectl query build.corp.example

Bundan sonra korporativ keçid corp.example daşıyır, qalanı isə ümumi resolverə xidmət edir. Sorğu səhv keçidə çatanda əmr ona cavab verən keçidin adını çəkir və bunu bilmək yalnız ünvanı bilməkdən yaxşıdır.

DNS dizaynını tunel növünə uyğunlaşdırın

Hər şeyi tuneldən keçirən məxfilik dizaynları bölgü siyahısı daşımamalıdır, çünki bu ümumi adları yerli resolverə qaytarıb niyyəti pozardı. Split-tunel dizaynlarına isə lazımdır: onsuz korporativ resolver hər ümumi sorğunu görür və tunel düşən an qurğu pozulur.

Sonra tuneldən kənar DNS-i bloklayan kill switch var. Adlar tunelin zonaları üçün həll olunur və bağlantı tam sağlam olduğu halda hər yerdə uğursuz olur. İşlək cavablar LAN resolveri üçün açıq icazə və ya yalnız korporativ zonanı ötürən yerli keşdir, hər ikisi isə tuneldə qüsur deyil, sahibi olan istisnadır.

İnterfeys başlayanda resolver konfiqurasiyasını yenidən yazan profil də təxminən eyni cür davranır: yerli resolver əlçatmaz olduqdan sonra yalnız tunelin bildiyi adlar həll olunur. Hansı mexanizm tətbiq olunursa, hər vəziyyətdə hansı adların işləməli olduğunu yazın və bu siyahını hesabatları qəbul edənə verin.

Hər keçid üzrə yoxlayın, sonra yenidən qoşulduqdan sonra təkrar yoxlayın

Bir daxili və bir ümumi ad soruşun və sorğunun həqiqətən hara getdiyini izləyin. Sızma yoxlama səhifəsi hansı resolverin cavab verdiyini deyir, sistemin hansı keçidi seçdiyini yox, ona görə indicə qurduğunuz sıralama haqqında heç nə demir.

Bağlantını kəsib yenidən qoşduqdan sonra iki sorğunu yenidən işlədin. Prioritetlər bağlantı aktivləşəndə yenidən tətbiq olunur və köhnə simvolik link heç kimin xatırlamadığı yeniləmədən sonra da qala bilər. Sonda yazmaq istədiyiniz şey hansı resolverin hansı şəkilçiyə sahib olduğu və sabah da qüvvədə qalan bir yoxlamadır.