Windows'da OpenVPN ulangandan keyin DNS nima uchun ishlamay qoladi

53-port hech qayerga yetmaydi, hal qiluvchi esa hanuz ping'ga javob beradi. block-outside-dns filtrlayotganini tekshiring, so'ng tunnel yeta oladigan hal qiluvchi bering.

Ofis hal qiluvchisiga ping "OpenVPN" ulangandan keyin ham javob oladi, shunga qaramay har bir nom qidiruvi muvaffaqiyatsiz tugaydi. Manzil yetib borish mumkin, port esa yo'q, Windows DNS'ni adapter bo'yicha filtrlashi mumkinligini bilganda bu uyg'unlik mantiqli bo'ladi. Profilda block-outside-dns bo'lsa, o'sha filtr birinchi gumondor, marshrutlar jadvali esa qidirish uchun noto'g'ri joy. Quyidagi ikki sinov qatlamlarni soniyalarda ajratadi.

Yetib boriladigan manzil, o'lik port

Muvaffaqiyatli ping xost ishlayotganini va yo'l borligini isbotlaydi. U 53-portga yetish ruxsati haqida hech narsa demaydi, chunki gapirilayotgan filtr boshqa qatlamda ishlaydi va adapterga bog'liq. Shuning uchun bir xil mashina ICMP'ga javob berib, o'sha manzilga yuborilgan har bir so'rovni rad etishi mumkin. Har qanday konfiguratsiyani o'zgartirishdan oldin ikki sinovni bir seansda o'tkazing.

ping <resolver-ip>
nslookup <name> <resolver-ip>

Aynan shu juftlik tashxisdir. Kichik tarmoqqa odatiy trafik davom etadi, nomlar yechimi esa o'ladi, odamlar server buzilgan yoki DNS hech qachon yuborilmagan degan xulosaga keladi. Ikki izohni ta'qib qilish qimmat, dalillar esa torroq joyga ishora qiladi. Har qanday sozlamaga tegishdan oldin juftlikni tasdiqlang.

Bu parametr filtrlash platformasining qoidasi

OpenVPN ma'lumotnomasi block-outside-dns'ni Windows Filtering Platform cheklovi deb ta'riflaydi, u ilovalarning tunneldan tashqaridagi adapterlarda DNS'ga yetishini to'xtatadi. U TCP va UDP 53-portni qamrab oladi. Filtr oddiy xavfsizlik devori qoidalari ro'yxatida emas, WFP ichida yashagani uchun boshqa joyda ruxsat qoidasi qo'shish natijani albatta o'zgartirmaydi. Shuning uchun DNS'ga ruxsat berish haqidagi oddiy maslahat muvaffaqiyatsiz bo'laveradi.

Sozlama import qilingan profildan yoki serverdan kelishi mumkin, oxirgi tahrirlagan faylingiz esa "mijoz nima yuklaganiga dalil emas". Amaldagi konfiguratsiya va ulanish jurnalini birga o'qing. Bu parametr Windows'ga xos ham, uni ko'chma deb hisoblash esa to'g'ri kelmaydigan maslahatlar beradi.

Ko'proq qoida qo'shish o'rniga shu cheklovga ega mijoz komponentini qidiring. Egasi — uni haqiqatan olib tashlay oladigan narsa.

Filtr hal qiluvchi emas

Tunneldan tashqari trafikni to'sish uning ichida ishlaydigan hal qiluvchi o'rnatmaydi. Parametr yo'lni olib tashlaydi va tunnelning DNS konfiguratsiyasini profilni tuzgan kishiga qoldiradi. Hech qachon hal qiluvchi yubormagan profilda endi bittasi ham yo'q.

Uch tekshiruvni tartib bilan bajaring. Birinchisi, muvaffaqiyatsiz ilova aslida qaysi hal qiluvchidan foydalanadi. Ikkinchisi, mijoz VPN DNS sozlamalarini qo'llaganmi. Uchinchisi, qaysi interfeys trafikni o'sha hal qiluvchiga olib boradi.

  1. Ishlatilayotgan hal qiluvchi: Resolve-DnsName -Server <resolver-ip> <name> natijasini ipconfig /all ro'yxatga olgan DNS serverlari bilan solishtiring.
  2. VPN DNS qo'llangan: tunnel adapterining DNS yozuvlarini o'sha ipconfig /all chiqishida ko'ring.
  3. Ishlatilgan interfeys: Find-NetRoute -RemoteIPAddress <resolver-ip> o'sha manzil uchun chiqish interfeysini nomlaydi.

Bu siyosat ostida LAN hal qiluvchisi loyihaga ko'ra yetib bo'lmaydigan bo'ladi, boshqa LAN trafigi ishlayotgan bo'lsa ham. Bu parametr o'z ishini qilmoqda. Agar loyihaga VPN orqali DNS kerak bo'lsa, hal qiluvchi ro'yxatini va tunnel yo'lini tuzating; agar mahalliy istisnolar bilan split DNS kerak bo'lsa, konfiguratsiya egasi o'sha istisnolarni qo'llab-quvvatlanadigan usulda ifodalashi kerak.

Bu parametr nimani qamramaydi

53-port nomlar yechimining hammasi emas. DNS over HTTPS va DNS over TLS boshqa transportdan foydalanadi, ba'zi ilovalar esa tizim sozlamalaridan qat'i nazar o'z hal qiluvchi mantiqini ishga tushiradi. Shuning uchun brauzer nomlarni yecha oladi, buyruq satri esa yo'q.

Bu farqni qarama-qarshilik emas, tashxis sifatida qabul qiling. Tizim hal qiluvchisi buzilgan deb qaror qilishdan oldin ikkalasini solishtiring.

Yozayotganda xulosani tor saqlang. Bu parametr bir platformada bir transportni cheklaydi, yechim yo'lining qolgani esa o'z egasiga ega alohida loyihalash savoli.

Uzilishdan oldin va keyin holatni tekshiring

O'sha qidiruvni ulanish paytida va ega mijoz uzilgandan keyin yana bir marta o'tkazing. Birinchisi tashqi hal qiluvchi uchun tunnel tik turganda muvaffaqiyatsiz bo'lishi kerak, ikkinchisi esa filtr olib tashlangach o'tishi kerak. Agar uzilishdan keyin ham muvaffaqiyatsiz bo'lsa, filtr tozalanmagan.

ipconfig /displaydns
nslookup <name> <resolver-ip>

Mijoz xizmatini yoki mashinani qayta ishga tushirish odatda eskirgan filtrni tozalaydi. Bu tashxisni tasdiqlaydi, ammo doimiy tuzatishni isbotlamaydi. Ko'rganingizni yozib qo'ying, chunki uzilishdan omon qolgan filtr buni yana qiladi, va aynan yozuv xato hisobotini oqlaydi.

Faqat shu tekshiruvlardan keyin hal qiluvchini almashtirish yoki xavfsizlik devori siyosatini qayta qurish mantiqli. Ikkalasi ham dalillar qo'llab-quvvatlaganidan kattaroq o'zgarishlar.

O'xshash maqolalar