Ommaviy DNS ishlashi Active Directory topiladi degani emas

VPN ulanadi, brauzer ommaviy saytni ochadi, noutbuk esa hali ham domenga kira olmaydi. Odatiy xulosa — nomlar hal bo’lgani uchun DNS joyida. U joyida emas, sababi brauzer sinovi domenga ulangan mijozga kerak bo’lgan zanjirdan faqat bitta so’rovni sinaydi. Domenni aniqlash avval xizmat yozuvlarini, so’ngra o’sha yozuvlar nomlagan kontrollerlarning manzillarini, so’ngra o’sha kontrollerlar tinglaydigan portlarga marshrutni so’raydi. Ommaviy javob bu qadamlarning birortasini qanoatlantirmaydi.

Afsona: nomlar hal bo’ladi, demak DNS tugadi

Ommaviy saytning hal bo’lishi faqat qandaydir hal qiluvchi ommaviy zonadagi nom uchun bitta A yoki AAAA so’roviga javob berganini bildiradi. Active Directory xuddi shu protokolni boshqa savol uchun ishlatadi: domen xizmatlari qayerda va bu mijoz qaysi kontrollerni ishlatishi kerak. Savol domen nomi bilan atalgan zona ostidagi SRV yozuvlari sifatida ifodalanadi, rekursiv ommaviy hal qiluvchining ularni saqlashga sababi yo’q.

Yozuv bo’lmasa, hal qiluvchi salbiy javob qaytaradi, bu uzilish emas, haqiqiy DNS javobi. So’ngra mijoz keshlangan kontroller ma’lumotiga qaytadi agar mavjud bo’lsa, va shuning uchun ish stoli soatlab yaxshi ko’rinib, qayta yuklash yoki parol o’zgarishidan keyin ishlamay qolishi mumkin.

Domen mijozi aslida nimani so’raydi, tartib bilan

corp.example kabi domen uchun umumiy lokator so’rovi _ldap._tcp.dc._msdcs.corp.example. SRV javoblari nomzod kontrollerlarni va ularning portlarini nomlaydi, so’ngra ulanish ochishdan oldin mijozga o’sha host nomlari uchun manzil yozuvlari kerak. Saytni biladigan aniqlash sayt subdomeni ostida so’rovlar qo’shadi, va javoblar qaysi kontrollerlar afzal ekanini belgilaydi, qaysi biri majburiy ekanini emas.

nltest /dsgetdc:corp.example
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.example

Zanjirni shu tartibda, muammo yuzaga keladigan tarmoqdan kuzatib boring. Yetib bo’lmaydigan manzilga hal bo’ladigan host nomi marshrutlash nosozligi, DNS nosozligi emas. Lokator yozuvlari yetishmaydigan yetib boriladigan kontroller DNS nosozligi, marshrutlash nosozligi emas. Ikkalasi o’xshash foydalanuvchi shikoyatlari va butunlay boshqa tuzatishlarni keltiradi.

Nega ommaviy hal qiluvchi javob beradi, kirish esa buziladi

Agar adapter mijozga ommaviy hal qiluvchi bersa, ommaviy nomlar ishlaydi, ichki nom maydoni ishlamaydi. Ikkinchi ommaviy hal qiluvchi qo’shish yordam bermaydi, chunki ikkalasi ham zonani ushlab turmaydi. “Avval ichki, keyin ommaviy” degan odatiy ro’yxat ham har bir domen uchun qoida kabi tutmaydi: birinchi serverning salbiy javobi qonuniy javob, va javob bo’sh bo’lgani uchungina mijoz ikkinchi serverni qayta sinamaydi.

Ikki ichki hal qiluvchi, agar ikkitasini ishlatsangiz, AD nom maydonini ushlab turishi va mijozning hozirgi tarmog’idan yetib boriladigan bo’lishi kerak. Bo’lingan tunnel loyihalari aynan shuni buzadi: VPN tunnel quyi tarmog’ini tashishi mumkin, ichki hal qiluvchi esa tunnel marshrutlamaydigan prefiksda turadi, shuning uchun so’rov javob bera olmaydigan hal qiluvchiga chiqadi.

Windows shuningdek muayyan nom maydonlarini muayyan serverlarga yo’naltira oladigan nom hal qilish siyosatini qo’llaydi, va adapter ko’rsatadigan DNS manzillari butun hikoya emas. O’sha siyosatni o’zgartirmasdan adapter ro’yxatini o’zgartirish amaldagi konfiguratsiyani tegmagan holda qoldirishi mumkin, va shuning uchun qo’llangandek ko’ringan tuzatishning hech qanday ta’siri yo’q.

Tunnel DNS va uning marshrutlarini uyg’un saqlang

Hal qiluvchini yuboradigan, lekin uni o’z ichiga olgan prefiksni yubormaydigan VPN profili mijoz yeta olmaydigan hal qiluvchi yaratadi; prefiksni yuborib, hal qiluvchini yubormaydigan profil mijozni mahalliyga so’rashga qoldiradi. Juftlikni bitta konfiguratsiya unsuri deb qarang va har bir profil o’zgarishidan keyin ikkalasini tekshiring, chunki qayta tartiblangan yuborish yoki yangi bo’lingan tunnel siyosati ularni ajratishi mumkin.

Mijoz yuborilgan sozlama bilan nima qilishini ham tekshiring. Ba’zi mijozlar DNS serverni faqat tunnel interfeysiga qo’llaydi va jismoniy adapterning hal qiluvchisini joyida qoldiradi, shuning uchun qaysi biri yutishi interfeys metrikasi va so’ralayotgan nomga bog’liq. Agar ichki javob faqat jismoniy adapter o’chirilganda kelsa, tuzatilishi kerak bo’lgan mexanizm shu, domen yozuvlari emas.

Aniqlash chaqiruvi va bitta tirik amal bilan qabul qiling

Foydali qabul sinovi lokator so’rovini ishga tushiradi va so’ngra bitta haqiqiy autentifikatsiyalangan amalni bajaradi, masalan katalogga asoslangan umumiy resursni ochish yoki chipta so’rash. Buni VPN o’tishidan oldin va keyin yana, xuddi shu mashinada, orasida qayta yuklashsiz bajaring. Keshlangan hisob ma’lumotlari va allaqachon ochilgan seanslar buzilgan yo’lni xursandchilik bilan sog’lom ko’rsatadi, shuning uchun ish stoliga muvaffaqiyatli kirish sinov emas.

Microsoft’ning DNS mijozi uchun tavsiyalari ichki nom maydonini hal qilish va ommaviy so’rovlarni yuqoriga uzatish o’rtasida xuddi shu chegarani tortadi, va VPN joriy etilganda saqlanishi kerak bo’lgan tartib shu.

Agar nosozlik faqat sekin bo’lsa, muvaffaqiyatsiz emas, kechikishni diagnostikadan alohida tuting. Aniqlash paytida vaqt tugashi yetib bo’lmaydigan kontrollerdan, bloklangan portdan yoki kech javob beradigan hal qiluvchidan kelishi mumkin, va ularning hech biri faqat kutish bilan isbotlanmaydi. Hal qiluvchi sozlamasini o’zgartirishdan oldin haqiqiy so’rovni, uning javobini va ulanish urinishini yozib oling.