VPN ulangan, lekin nomlar hal bo'lmayapti: DNS aslida qayerda buziladi

Tunnel ko'tarilgan, belgi yashil, va brauzerning har bir varag'i nom hal qilish xatosini bildirmoqda. Bu manzarani uch xil mexanizm yaratadi: resolver yetib bo'lmaydigan bo'lishi mumkin, klient siz kutmagandan resolverdan so'rayotgan bo'lishi mumkin, yoki faqat xususiy nomlar muvaffaqiyatsiz bo'lishi mumkin. Tunnel protokolida biror narsani o'zgartirishdan oldin ularni ajrating, chunki har biri boshqa joyda tuzatiladi. Quyidagi tartib uchtasini ajratadigan kuzatishlardan boshlanadi.

So'rov aslida nimaga muhtoj

So'rov uchta narsaga muhtoj: resolver manzili, shu manzilga marshrut va savolga mos javob. Har biri alohida muvaffaqiyatsiz bo'lishi mumkin, va ko'rinadigan alomat yuklanmaydigan o'sha sahifadir. Shuning uchun xato sahifasi uchtadan qaysi biri buzilganini bilmaguningizcha sizga deyarli hech narsa aytmaydi.

Klient o'z resolverini VPN profilidan, tunneldagi DHCPdan yoki o'z konfiguratsiyasidan o'rganadi, qaysi manba g'alaba qozonishi platformaga bog'liq. Windows'da ipconfig /all har bir adapter bo'yicha DNS serverlarini ko'rsatadi, shuning uchun yuborilgan qiymat haqiqatan yetib kelganini ko'rasiz. Operatsion tizimga hech qachon yetib bormagan yuborilgan qiymat jimgina va odatiy nosozlikdir. Profilga tegishdan oldin sozlangan qiymatni o'qing.

Linux va macOS bir xil savolga boshqa buyruqlar bilan javob beradi, va javob ham xuddi shunday o'qishga arziydi: resolvectl status va scutil --dns ikkalasi ham serverlarni interfeys bo'yicha sanaydi. Bu ro'yxatni profil yuboradi deb da'vo qilgan manzil bilan solishtiring. Bu yerdagi nomuvofiqlik quyidagi hamma narsani izohlaydi, shuning uchun nomlarni sinashdan oldin uni hal qiling.

Bitta ommaviy va bitta xususiy nomni sinab ko'ring

Bir xil mashinadan oddiy ommaviy xost nomi va hujjatlashtirilgan xususiy xost nomini so'rang, va qaysi server qaysi biriga javob berganini yozib qo'ying. Ikkalasi ham muvaffaqiyatsiz bo'lsa, resolver yoki uning marshruti buzilgan. Faqat xususiy nom muvaffaqiyatsiz bo'lsa, resolver javob bergan va savol zona yoki marshrutlashga aylanadi. Marshrut o'zgarishi farqni izohlay olmasligi uchun ikkala so'rovni bir daqiqa ichida bajaring.

Ichki nomlarni ommaviy skrinshotlardan va ommaviy resolverlardan uzoq tuting. Vaqt tugashi va mavjud bo'lmagan domen haqidagi javob har xil kuzatishlardir: birinchisi hech narsa qaytmaganini, ikkinchisi bir hokimiyat nom mavjud emasligini javob berganini bildiradi. Ikkalasini bitta xato deb qabul qilish sizni noto'g'ri qatlamga olib boradi, sertifikat ogohlantirishi esa yana uchinchi narsa, DNS nosozligi emas.

nslookup so'ralgan serverni ham, olingan javobni ham chop etadi, va bu sizga kerak bo'lgan juftlikdir. Uni bir xil qobiqda ikki marta ishga tushiring va javob bergan manzilni har bir javob yoniga yozing.

nslookup example.com
nslookup host.corp.example 10.20.30.53

Klient haqiqatan o'sha serverga yeta olishini tasdiqlang

Profil yuborgan xususiy resolver faqat tunnel ko'tarilganda klient unga yeta olsagina foydali. To'g'ri ko'rinadigan manzil marshrutsiz vaqt tugashini keltirib chiqaradi, tunnelning ulangan holati esa bu marshrut haqida hech narsa aytmaydi. Tekshiruv VPN oxirgi nuqtasiga emas, resolverning o'ziga qaratilgan marshrut izlashdir.

Har bir platforma bunga bir satrda javob beradi, va chiqishda nomlangan interfeys butun javobdir. Agar u resolver tunnel orqasida turganda jismoniy adapterga ishora qilsa, profil uni qamrab oladigan prefiks yubormayapti.

ip route get 10.20.30.53                      # Linux
route -n get 10.20.30.53                     # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53   # Windows PowerShell

Bo'lingan tunnel profilida resolver yuborilgan marshrutlardan tashqarida turishi mumkin, bu server emas, profil muammosi. Resolver manzilini yuborilgan prefikslar bilan solishtiring va ulardan biri uni qamrab olishini tasdiqlang. Xuddi shu nomuvofiqlik DNS bir tarmoqda ishlab, bir xil profilli boshqasida nima uchun muvaffaqiyatsiz bo'lishini izohlaydi.

Brauzerlar tizim resolverini chetlab o'tishi mumkinligini unutmang

Xavfsiz DNS yoqilgan brauzer so'rovlarni HTTPS orqali o'zi tanlagan provayderga yuborishi va operatsion tizim resolverini butunlay e'tiborsiz qoldirishi mumkin. Shunda tizim to'g'ri ko'rinadi, brauzer esa muvaffaqiyatsiz bo'ladi, yoki aksincha. Bu tunnel uchun emas, brauzer uchun siyosat masalasi.

Brauzerning xavfsiz-DNS sozlamasini va uni boshqaradigan har qanday boshqariladigan siyosatni tekshiring, so'ng tunnel o'zgarmagan holda ikkinchi ilova yoki brauzerni sinab ko'ring. Faqat bitta ilova muvaffaqiyatsiz bo'lsa, tuzatish o'sha ilovaga tegishli. Xususiy oyna toza taqqoslash emas, chunki u bir brauzerda kengaytmalarni standart bo'yicha o'chirib qo'yishi mumkin, boshqasida esa yo'q, va u hech qachon boshqariladigan siyosatni chetlab o'tmaydi. Buning o'rniga ikkinchi brauzer profili yoki boshqa ilovadan foydalaning.

Keshni tozalang va haqiqiy vazifani qayta sinang

Sozlamani tuzatgandan so'ng mahalliy resolver keshini tozalang, eski javob tuzatishdan uzoq yashamasligi uchun. Qisqa tiklanishdan keyin yangi nosozlik sabab hali ham borligini bildiradi, tozalash muvaffaqiyatsiz bo'lganini emas. Uch kesh alohida bo'lgani uchun o'zingiz ishlatayotgan mashinaga mos satrni tanlang.

ipconfig /flushdns                 # Windows
resolvectl flush-caches            # Linux
sudo killall -HUP mDNSResponder    # macOS

So'ng sintetik so'rov o'rniga asl vazifani takrorlang, chunki foydalanuvchi uchun muhimi vazifaning o'zi. Bir marta qayta ulanib oling, qayta sinov foydalanuvchi haqiqatan bo'ladigan holatni qamrab olishi uchun. Microsoft'ning nslookup ma'lumotnomasi so'rov argumentlari uchun saqlab qo'yishga arziydigan sahifa.

Agar nomlar faqat uzilgandan keyin muvaffaqiyatsiz bo'lsa, klient oldingi konfiguratsiyani tiklamagan, bu DNS serverni almashtirish o'rniga xabar qilinishi kerak bo'lgan hayot tsikli xatosi. Ishlaydigan so'rov ham oqish testi emas, chunki chiqish mamlakati qaysi resolver javob berganini aytmaydi.