OpenVPN surgan DNS e'tiborsiz qoldiriladi: uni qaysi komponent qo'llaydi

Jurnal server surgan variantni ko'rsatadi, tunnel ishlayapti, ammo ichki nomlar hali ham hal bo'lmaydi. Rezolverga to'g'ridan-to'g'ri so'rov javob beradi, demak server joyida, lekin har bir dastur baribir mahalliy marshrutizatordan so'raydi. Mijozga yetib kelgan narsa taklif, rezolverdagi o'zgarish emas, va nomlarni hal qilishga ega komponent Linux, Windows va macOS'da farq qiladi. Variantni egasidan ajratsangiz, to'rt nosozlik deyarli har bir hisobotni qamrab oladi: hook yo'q, ikkita raqobatdosh hook, loyihaga muvofiq ishlayotgan bo'lingan DNS, yoki server emas, qo'shimcha talab qiladigan qisqa nom.

Surilgan variant taklif, o'rnatish emas

Serverda ikkita direktiva natijani emas, niyatni tavsiflaydi:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

Mijoz sozlangan rezolverni olmaydi. U muhit o'zgaruvchilarini oladi, foreign_option_1 va keyingilarini, har bir surilgan qator uchun bittadan, va mahalliy narsa ularni o'qib, operatsion tizimning rezolver holatini qayta yozishi kerak. Linux'da sukut bo'yicha hech narsa buni qilmaydi, shuning uchun to'g'ri server va ulangan mijoz hali ham LAN orqali nomlarni hal qila oladi.

Ikki uch orasida uch bosqich bor: surish yetib borishi, mijoz uni ochib berishi va hook uni qo'llashi kerak. O'rta bosqichni mijoz jurnalida, oxirgisini rezolver holatida o'qing, hech qachon teskari emas, chunki bitta jurnal satri faqat birinchi ikkitasini isbotlaydi.

Surish yetib kelganini tasdiqlang va egasini toping

Ishga tushiruvchini nomlashdan boshlang: oddiy openvpn buyruq, systemd nusxasi, NetworkManager yoki ishlab chiqaruvchi mijozi. Bu hook qayerda yashashi mumkinligini belgilaydi. systemd-resolved bor xostda, resolvectl status har bir ulanishni u haqiqatda ishlatadigan DNS serverlari va qidiruv domenlari bilan sanab chiqadi, tunnel ulanishi esa har doim tun0 deb nomlanmaydi.

Agar surilgan manzil jurnalda bo'lib, hech bir ulanishda bo'lmasa, integratsiya yetishmaydi. Agar u ulanishda bo'lib, so'rovlar hali boshqa joyga chiqsa, muammo shundaki, qaysi so'rovlar o'sha ulanishni tanlaydi. NetworkManager dns=dnsmasq faylida /etc/NetworkManager/NetworkManager.conf bo'lingan DNS'ni ataylab qo'llaydigan mahalliy uzatgichni ishga tushiradi: VPN domeni ichidagi nomlar VPN rezolveriga boradi, qolgan hamma narsa avvalgi yo'lini saqlaydi. Butun trafik ko'chadi deb kutganingizda bu xatti-harakat nosozlikday ko'rinadi; har bir ulanish sozlamalarini tekshiring nmcli connection show "My VPN" bilan, bu yerda ipv4.dns va ipv4.dns-search qurilma xabar bergan narsa orqasidagi qiymatlarni saqlaydi, uni buzilgan deb atashdan oldin. Agar har bir so'rov haqiqatan VPN rezolveriga yetishi kerak bo'lsa, olib tashlang dns=dnsmasq ni NetworkManager.conf fayldan va NetworkManager'ni qayta ishga tushiring, bu nomlarni hal qilishni ulanish sozlamalariga qaytaradi; aks holda bo'lingan DNS'ni saqlang va surilgan domen ro'yxatini tuzating.

Linux: variantlarni rezolverga bering

Distributiv paketlar buning uchun hook beradi, mijozga uni ishga tushirishga ruxsat bo'lishi kerak. systemd-resolved bo'lmagan xostda odatiy tartib:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

systemd-resolved bilan eski resolv.conf skripti muhim hech narsani o'zgartirmasligi mumkin, chunki stub rezolver har bir ulanish bo'yicha holatni saqlaydi. update-systemd-resolved yordamchi quyidagini ishlatadigan hook shaklini hujjatlashtiradi up-restart va down-pre, bu interfeys bitta ulanish urinishidan uzoq yashaganda muhim. Nima tanlasangiz ham, holatga bitta komponent ega bo'lishi kerak. NetworkManager yoniga aloqasiz hook qo'shish bitta ulanishga ikki yozuvchi beradi, va natija endi sizning konfiguratsiyangizga emas, tartibga bog'liq bo'ladi.

NetworkManager surilgan variantni butunlay e'tiborsiz qoldirgan holat ham bor: server manzili ulanishning IPv4 sozlamalariga kiritilmaguncha shunday edi, keyin rezolver holati u ishlatilayotganini ko'rsatdi. Skriptlarni qayta yozishdan oldin buni sinab ko'rishga arziydi, chunki u muammoni shell hook'dan tunnelni allaqachon ko'tarib yurgan ulanish profiliga ko'chiradi.

Windows va macOS turli qismlarni qo'llaydi

Windows mijozi VPN adapterining DNS serverlarini haqiqatan o'rnatadi, lekin Windows hali ham metrika bo'yicha interfeys tanlaydi va qisqa nomni kengaytirish uchun hali ham qo'shimcha kerak. Profilni emas, adapter holatini tasdiqlang:

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

Agar manzil yo'q bo'lsa, uni bu bilan o'rnating Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, keyin qo'shimchani adapterning IPv4 xossalariga qo'shing, shunda fileserver bo'ladi fileserver.corp.example. Butun mashina bo'ylab SearchList qiymati Tcpip\Parameters ostida xuddi shunday qiladi. Uzoq nom hal bo'lib, yalang'och nom hal bo'lmagan joyda rezolver allaqachon to'g'ri, ayb esa qidiruv ro'yxatida. Tuzatishlar tartib bilan: suring DOMAIN mijoz qo'shimchani o'rganishi uchun, o'sha qo'shimchani adapter yoki ulanishning qidiruv ro'yxatiga qo'shing, va vaqtinchalik chora sifatida nomni hosts faylida mahkamlang, yoki LMHOSTS ichida Windows'da; NetBIOS ko'rib chiqish marshrutizatordan o'tmaydi, shuning uchun ofis LAN'ida qisqa nom topadigan eshittirish hech qachon tunnel mijoziga yetib bormaydi.

block-outside-dns block-outside-dns Windows mijozining xatti-harakati, ko'chiriladigan profil satri emas, va uni Linux yoki macOS profiliga ko'chirish u yerda uni qayta hosil qilmaydi. Agar Windows'da umumiy nomlar ishlab, ichki nomlar ishlamasa, Kengaytirilgan sozlamalar ostidagi adapter tartibini bu bilan solishtiring ipconfig /all. macOS'da har bir xizmat uchun rezolver tartibi tizimga tegishli, shuning uchun scutil --dns bilan qaysi domen uchun qaysi rezolver so'ralishini ko'ring va har qanday yakka xabar qilingan profil tuzatishini umumiy emas, mijozga bog'liq deb biling.

Xuddi shu noutbukdagi virtual mashina bundan hech narsa meros olmaydi. Mehmon ichki domen uchun o'z rezolver yozuvini bering, yoki gipervizorning NAT'i uning so'rovlarini xost orqali uzatsin, bu faqat xost tunnel'i ishlab turganda to'g'ri.

Tarix uchinchi sabab. Avvalgi profildagi DNS serverlari yoki qo'shimcha sozlamalari qayta ulanishlardan omon qolishi mumkin, shuning uchun adapter to'g'ri ko'rinib, qidiruvlar hali ishlamasa, tirik adapterni bu bilan solishtiring Get-VpnConnection va serverga tegishdan oldin eskirgan yozuvni o'chiring yoki qayta yozing.

So'rov qayerga ketganini isbotlang

Bitta qidiruv paytida olingan yozib olish bahsni hal qiladi: tcpdump -ni eth0 port 53 fizik interfeysda so'rovlarni ko'rsatadi, ya'ni ular tunneldan tashqariga chiqadi va rezolver hech qachon almashtirilmagan. dig @10.8.0.1 name.corp.example keyin qolgan ikki holatni ajratadi. Agar to'g'ridan-to'g'ri so'rov javob bersa, rezolver ishlaydi va mijoz undan foydalanmaydi; agar vaqt tugasa, rezolver tunnel orqali yetib bo'lmaydigan joyda va hech qanday mahalliy o'zgarish yordam bermaydi.

Agar hali ishlatilayotgan rezolver provayder bergani bo'lsa, tunnel trafikni shifrlaydi, ammo nomlar o'sha provayderga ko'rinib qoladi. Bu funksionallik emas, oqib chiqish masalasi, va o'sha yozib olish unga javob beradi: fizik interfeysdagi so'rov tunneldan tashqaridagi kimgadir ketadi.

Yetib borish VPN xostidagi xavfsizlik devorini ham o'z ichiga oladi, u hovuzdan UDP va TCP 53 ga ruxsat berishi kerak. Yopiq port xuddi buzilgan surishday ko'rinadi, va tunnel tarmog'ining ichidan javob beradigan rezolver ham shunday. Bir marta uzib, qayta ulangandan keyin yozib olishni takrorlang, chunki birinchi ulanishda paydo bo'lib, ikkinchisida yo'qoladigan sozlamalar hook'dagi hayot sikli nosozligi, yo'qolgan variant emas.

Bitta egasini saqlang va tartib bilan tekshiring

Taxmin qilingan tunnel holatiga asoslanib adapterni DNS'ini qayta yozadigan skript profil allaqachon ko'tarib yurgan konfiguratsiyani takrorlaydi, va taxmin birinchi marta xato bo'lganda jimgina muvaffaqiyatsiz bo'ladi. Ulanishning o'z DNS sozlamalarini yoki bitta hujjatlashtirilgan hook'ni afzal ko'ring, va qaysi birini tanlaganingizni yozib qo'ying, keyingi odam ikkinchisini qo'shmasin.

Siklni to'rt tekshiruv bilan yoping: surilgan manzil tunnel ulanishida bor, ichki nom to'liq malakali nom sifatida hal bo'ladi, o'sha nom qo'shimchasiz hal bo'ladi, va bir marta qayta ulangandan keyin ikkisi ham to'g'ri. Bitta yozib olish to'rttadan qaysi biri muvaffaqiyatsiz bo'lganini aytadi. OpenVPN 2.6 qo'llanmasi sanab chiqadi dhcp-option va skript direktivalarini platforma izohlari bilan birga.