VPN DNS har bir so’rovni o’ziga oladi: NetworkManager’da dns-priority’ni tuzating

Ofis VPN-iga ulanib ko’ring, va birdan har bir nom so’rovi korporativ resolver-ga ketadi. Ommaviy nomlar hali ham hal bo’ladi, shuning uchun mahalliy printer nomi ishlamaguncha yoki split-horizon yozuvi ofis manzilini qaytarmaguncha hech narsa buzilgandek ko’rinmaydi. Ba’zi Fedora sozlamalarida buning aksi bo’ladi: provayder resolver-i tunnel ko’tarilgandan keyin ham javob berishda davom etadi. Ikkalasi ham bitta savol — bu so’rovning egasi qaysi resolver — va NetworkManager tizimlarida javob har bir ulanishning DNS xossalarida yashaydi.

Ikki ulanish, bitta g’olib resolver

Har bir ulanish DNS ustuvorligini e’lon qiladi. Oddiy ulanishlar sukut bo’yicha 50, VPN ulanishlari esa 0 bo’ladi va kichik qiymat g’olib bo’ladi. Aynan shu sukut sababli VPN ulanishi o’zi talab qilgan har bir domen uchun simli ulanishdan jimgina o’tib ketadi: nol hech kim tanlamasdan ellikni yutadi.

Ustuvorlik nomzodlarni tartibga soladi. U g’olibdan nima so’ralishini cheklamaydi. Qidiruv domeni bo’lmagan VPN ulanishi hamma narsani talab qiladi, shuning uchun uni afzal ko’rish ommaviy so’rovlarni ham tunnelga, bo’lingan tunnel loyihasida esa korporativ resolver yo’naltiradigan joyga yuboradi.

Ustuvorlik tartibni, qidiruv ro’yxati egalikni belgilaydi

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

Qidiruv ro’yxati egalik bayonotidir. corp.example kabi yalang’och domen qidiruv qo’shimchasi va marshrutlash domeniga aylanadi. Faqat marshrutlash shakli ~corp.example shu qo’shimcha ostidagi so’rovlarni domenni qisqa nomlarga qo’shmasdan shu ulanishga yuboradi. O’sha tilda «bu serverdan so’ra» va «bu serverdan so’ra va yozishimni tugat» o’rtasidagi farqdir.

Foydalanuvchilar qisqa xost nomlarini yozganda va yozuvlar to’liq malakali nomlar bilan ham manzillanganda ikkala shakldan foydalaning. Faqat marshrutlash shaklini bo’linish kerak bo’lganda, resolver yalang’och nomni qanday to’ldirishini o’zgartirmasdan ishlating.

So’ngra afzallikni aniq qilib, ulanishni qayta faollashtiring:

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"

Manfiy ustuvorlik «bu ulanishni afzal ko’r» deyishning hujjatlashtirilgan yo’li, ikkala manzil oilasini ham belgilash esa IPv6 ulanishi bo’lgan xostda xatti-harakatni bir xil saqlaydi. Xususiyatni ulanishni qayta faollashtirmasdan o’zgartirish hozir ishlab turgan hech narsani o’zgartirmaydi, shuning uchun ketma-ketlik aniq up bilan tugaydi.

Bo’linishni systemd-resolved ushlab tursin

Sukut bo’yicha dnsmasq plagin so’rovlarni bitta mahalliy resolverga quyadi, shuning uchun har bir havola bo’yicha ajratish qo’pol bo’lib qoladi. systemd-resolved bo’linishni har bir havola uchun ko’rsatadi, resolvectl query esa javob bergan havolani nomlaydi.

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

Shundan keyin korporativ havola corp.example ni olib yuradi, ommaviy resolver esa qolganini xizmat qiladi. So’rov noto’g’ri havolaga yetib borganda, buyruq unga javob bergan havolani nomlaydi va buni bilish faqat manzilni bilishdan yaxshiroq.

DNS loyihasini tunnel turiga moslang

Hamma narsani tunnel orqali yuboradigan maxfiylik loyihalari bo’linish ro’yxatini olib yurmasligi kerak, chunki u ommaviy nomlarni mahalliy resolverga qaytarib, maqsadni bekor qiladi. Bo’lingan tunnel loyihalariga esa u kerak: usiz korporativ resolver har bir ommaviy so’rovni ko’radi va sozlama tunnel yiqilgan paytda buziladi.

So’ngra tunneldan tashqari DNS-ni bloklaydigan kill switch bor. Nomlar tunnel zonalari uchun hal bo’ladi va qolgan hamma joyda muvaffaqiyatsiz bo’ladi, ulanish esa butunlay sog’lom. Ishlaydigan javoblar LAN resolveriga aniq ruxsat yoki faqat korporativ zonani uzatadigan mahalliy keshdir, va ikkalasi ham tunneldagi nuqson emas, egasi bor istisno.

Interfeys ishga tushganda resolver konfiguratsiyasini qayta yozadigan profil ham deyarli shunday yo’l tutadi: mahalliy resolver yetib bo’lmaydigan bo’lgach, faqat tunnel bilgan nomlar hal bo’ladi. Qaysi mexanizm amal qilmasin, har bir holatda qaysi nomlar ishlashi kerakligini yozib qo’ying va bu ro’yxatni hisobotlar bilan shug’ullanadigan kishiga bering.

Har bir havola bo’yicha tekshiring, so’ngra qayta ulangandan keyin yana tekshiring

Bitta ichki va bitta ommaviy nomni so’rang, va so’rov aslida qayerga ketishini ko’ring. Oqish tekshiruvi sahifasi qaysi resolver javob berganini aytadi, tizim qaysi havolani tanlaganini emas, shuning uchun hozir sozlagan tartibingiz haqida hech narsa demaydi.

Uzib, qayta ulangandan keyin ikkala so’rovni yana ishga tushiring. Ulanish faollashganda ustuvorliklar qayta qo’llanadi, eski ramziy havola esa hech kim eslay olmaydigan yangilanishdan keyin ham qolishi mumkin. Oxirida yozib qo’ymoqchi bo’lgan narsangiz — qaysi resolver qaysi qo’shimchaning egasi ekani, qo’shimcha ertaga ham amal qiladigan tekshiruv bilan.