Nima uchun shaxsiy DNS nomlari VPN mijozlarida ishlamaydi va qayerda tekshirish kerak

Mehmonxona xonasida noutbukni ochasiz, mijozni ishga tushirasiz, ichki fayl serverining nomini yozasiz va hech narsa olmaysiz. Tunnel ulanganini bildiradi va xuddi shu quyi tarmoqdagi manzilga ping hali ham javob beradi, demak transportning o'zi joyida. Faqat nom ishlamaydi va bu bo'shliq muammoni ikki joyga toraytiradi: mijoz qaysi hal qiluvchidan so'radi va olgan javobi tunnel orqali qaytishi mumkinmi. Birini tuzating, ikkinchisini tashlab keting va nosozlik shunchaki joyini o'zgartiradi.

Har qanday profilni tahrirlashdan oldin mijozning nom bilan nima qilishini tekshiring. Linuxda resolvectl query files.corp.example javobni qaysi ulanish va qaysi hal qiluvchi yaratganini ko'rsatadi. Windowsda Resolve-DnsName files.corp.example javob bergan serverni va u qaytargan manzilni ko'rsatadi.

Biror narsani o'zgartirishdan oldin javobni o'qing

Nom bir necha millisekund ichida NXDOMAIN bo'lib qaytsa, so'rov sizning zonangizga hech qachon yetmagan va uning o'rniga qandaydir ommaviy yoki mehmonxona hal qiluvchisi javob bergan. Uzoq tanaffusdan keyin qaytsa, yo'lda nimadir UDP 53 portini tashlamoqda va mijoz oxir-oqibat zaxiraga o'tgan. To'g'ri manzil bilan javob beradi, ammo ulanish hali ham tiqilib qolsa, qidiruv joyida va muammoingiz marshrutlashda yoki xizmatning o'zida.

Bu uchga bo'lish bir soat taxminni tejaydi. Shuningdek, VPNga umuman tegish kerakmi yoki yo'qmi, aytadi: to'g'ri shaxsiy manzilga hal qilinadigan nom allaqachon hal qiluvchi yo'lini isbotlagan, demak qolgan ish ma'lumot yo'lida.

Hal qiluvchini tunnelning ichidan tarqating

Mijozlar ikki guruhga bo'linadi. Biriga server ulanish o'rnatilayotganda hal qiluvchi tayinlashi mumkin; ikkinchisi sozlamani hech qanday shlyuz masofadan o'zgartira olmaydigan mahalliy faylda saqlaydi.

OpenVPN birinchi guruhda. Serverda push "dhcp-option DNS 10.8.0.53" va push "dhcp-option DOMAIN corp.example" boshqaruv kanali orqali tushadi, lekin mijoz konfiguratsiyasida pull hali yoqilgan bo'lsa. Qo'lda tahrirlangan va pull-filter ignore "dhcp-option" ni olib yuruvchi mijoz ularni hech qachon ko'rmaydi va o'sha bitta satr «server buni itaryapti, ammo noutbukim rozi emas» degan hayratlanarli ko'p holatlarni tushuntiradi.

WireGuard ikkinchi guruhda, chunki protokolda umuman variant muzokarasi yo'q. Hal qiluvchi va qidiruv domeni mijozning o'z [Interface] blokiga DNS = 10.8.0.53, corp.example sifatida kiradi. wg-quick buni resolvconf yoki systemd-resolved orqali qo'llaydi va Windowsda rasmiy mijoz faqat tunnel ko'tarilganda mavjud bo'ladigan NRPT qoidalarini o'rnatadi: Get-DnsClientNrptPolicy ularni sanab chiqadi, bu esa mijoz faylingizni qachonlardir qo'llagan-qo'llamaganini ko'rishning tez usuliga aylanadi.

IPsec/IKEv2 o'rtada turadi. strongSwan'ning attr plagini hovuzdan olingan DNS serverni qaytarishi mumkin va Windows mijozi buni odatda qabul qiladi, ammo o'z nom serverini qotirib qo'ygan profil shlyuz taklif qilgan hamma narsadan ustun bo'ladi. Linux mijozida ekvivalent qo'l qadami resolvectl dns wg0 10.8.0.53 va undan keyin resolvectl domain wg0 '~corp.example'; ikkisi ham interfeys bilan birga yo'qoladi, bu esa tunnelga bog'langan sozlama uchun aynan kerakli narsa.

Har bir so'rovni yutish o'rniga qo'shimchani chegaralang

Mijozning butun hal qiluvchilar ro'yxatini ichki serveringizga yo'naltirish oson va odatda noto'g'ri. Shunda har bir ommaviy nom ma'lumot markazingizning chiqishidan hal qilinadi, CDNlar uzoq manzillarni qaytaradi va hal qiluvchining bitta uzilishi foydalanuvchining ko'rishini ham o'zi bilan olib ketadi.

Ichkariga faqat shaxsiy qo'shimchani yuboring. systemd-resolvedda ~ bilan boshlanadigan domen faqat marshrutlash uchun, ya'ni ~corp.example o'sha qo'shimcha ostidagi so'rovlar o'sha ulanish serverlariga borishini, qolgan hamma narsa esa jismoniy tarmoqdan foydalanishda davom etishini bildiradi. Windows xuddi shu ishni nom maydoniga chegaralangan NRPT qoidalari bilan, macOS esa /etc/resolver/ ostidagi qo'shimcha hal qiluvchi fayli bilan bajaradi.

Multicast nomlari o'z javobiga loyiq. .local nomlari dizayni bo'yicha link-local (RFC 6762) va nuqtadan nuqtaga tun interfeysi bu multicast guruhini tashimaydi, shuning uchun qo'shimcha ommaviy hal qiluvchi ularni e'lon qilmaydi va ichki unicast hal qiluvchidan ular haqida so'rasangiz NXDOMAIN qaytadi. avahi kabi aks ettiruvchi aks ettirish rejimida ikki segmentni bog'lashi mumkin, ammo bu hech bir mijoz talab qila olmaydigan server tomonidagi qaror. Printer yoki NAS nom bilan ochiq bo'lishi kerak bo'lsa, uning o'rniga zonangizda unga A yozuvi bering.

Javob qaytishi mumkinligini isbotlang

Yetib bo'lmaydigan manzilga ishora qiluvchi to'g'ri javob marshrutni tekshirmaguningizcha aynan hal qiluvchi muammosi kabi ko'rinadi. Yadrodan javob qayerga ketishini so'rang: ip route get 10.20.5.20 interfeysni va foydaliroq bo'lgani, foydalanadigan manba manzilini nomlaydi.

Hal qiluvchining manzilini o'zini kuzatib boring. DNS = 10.8.0.53 yonida AllowedIPs = 10.20.0.0/16 bo'lgan mijoz so'rovlarini jismoniy NIC orqali tashqariga yuboradi, u yerda ular jimgina o'ladi, chunki hal qiluvchi tunnel da'vo qiladigan hech bir prefiks ichida emas. Bu nomuvofiqlik butun bu sohada eng ko'p uchraydigan yagona sababli nosozlikdir va DNS sozlamasini ruxsat etilgan prefikslar bilan satrma-satr solishtirmaguningizcha ko'rinmay qoladi.

Ustma-ust tushuvchi diapazonlar qarama-qarshi nosozlikni keltirib chiqaradi. Javob to'g'ri, marshrut bor va noto'g'ri xostga ishora qiladi, chunki uydagi 192.168.0.0/24 tunnelning xuddi shu diapazonga marshrutidan aniqroq. Bir tomonni qayta raqamlang yoki torroq marshrutni itarib yuboring, so'ngra xizmat xostining xavfsizlik devori va qaytish yo'lini tasdiqlang; strongSwan'ning yo'naltirish haqidagi eslatmalari o'sha yo'lning sysctl tomonini qamrab oladi.

Sertifikatlar odamlar DNSga yuklaydigan alohida shaxs tekshiruvidir. Brauzer hal qilish xatosi o'rniga nom nomuvofiqligini xabar qilsa, qidiruv allaqachon ishlagan va tuzatilishi kerak bo'lgan narsa sertifikatdagi SANdir. HTTPSni nom bilan sinang, hech qachon yalang'och IP bilan emas.

Shlyuzdan emas, mijozdan qayta sinang

Foydalanuvchi shikoyat qilayotgan ilovaning ichida sinang, chunki buyruq satridagi qidiruv brauzer xuddi shu yo'ldan ketishini isbotlamaydi. Chrome'ning xavfsiz DNSi va Firefox'ning network.trr.mode sozlamasi tizim hal qiluvchisini butunlay chetlab o'tishi mumkin va ular buni qilganda shaxsiy nom yo ishlamaydi, yo ommaviy hal qiluvchiga oqib ketadi. resolvectl query ni qo'lda ishga tushirilgan dig @10.8.0.53 files.corp.example bilan solishtirish ikkisidan qaysi biri sodir bo'lganini aytadi.

So'ngra tuzatildi demasdan oldin ulanishni uzib, qayta ulang. Interfeysga qo'lda qo'yilgan sozlamalar interfeys bilan birga yo'qoladi va faqat unutilgan mahalliy o'zgarish tufayli to'g'ri ko'ringan profil keyingi ishga tushishda ishlamaydi.

Keyingi mashina uchun qisqa ro'yxat: nom tunnel hal qiluvchisi orqali hal qilinadi, qo'shimcha global emas, chegaralangan, hal qiluvchi manzili ruxsat etilgan prefikslar ichida, javobdagi xost xizmat portida javob beradi va sertifikat foydalanuvchi yozgan nomni qamrab oladi.