Bo'lingan DNS va VPN: domen qoidalari IP marshrutlari emas
Bo'lingan DNS hal qiluvchini nom bo'yicha tanlaydi, javobga esa hamon marshrut kerak. Domen qoidasi va yo'lni alohida, haqiqatan ishlatadigan platformada sinab ko'ring.
Noutbuki intranet.corp ni tunnel orqali hal qiladi, gitlab.com esa provayder hal qiluvchisiga borishda davom etadi, va bu loyihalangandek ishlaydigan tuzilma. Uni ikki alohida qaror yaratdi: nom mosligi qoidasi hal qiluvchini tanladi, marshrut esa javobni qaytardi. Har qaysisini buzsangiz, brauzer tashqaridan bir xil ko'rinadigan nosozlikni ko'rsatadi. Bo'lingan DNS haqidagi hisobotlarning ko'pchiligi ikkinchi nosozlikni tasvirlab, birinchisi haqida dalillar keltiradi.
Ikki yarim har xil joylarda yashaydi va odatda ularni har xil odamlar tahrir qiladi. Biri VPN profiliga bog'langan DNS siyosati, ikkinchisi tunnel o'rnatadigan yoki ushlab turadigan marshrutdir. Qaysi yarim haqiqatan siljiganini hech kim aniqlamasa, nosozliklarni tuzatish to'xtaydi.
Bitta so'rovda yashiringan ikki qaror
Nom yarmi marshrut emas, siyosat obyekti. Windows da bu VPN profildagi nomni hal qilish siyosati; Apple platformalarida DNS sozlamalari obyektidagi mos domenlar to'plami; Linux da marshrutlash domeni, bo'lingan hal qiluvchi satri yoki nom xizmati kalitining tartibi. Yo'l yarmi oddiy marshrutlash bo'lib, tunnel yoki qo'l bilan o'rnatiladi va u host nomi nima ekanini bilmaydi. Qo'shimchani qabul qiladigan profil faqat kim javob berishini hal qiladi; u javobni hech qachon yetib boriladigan qilmaydi.
Tez alomat testi ularni ajratadi: nomni manzil bilan almashtiring. Manzil ishlasa, yo'l joyida va qoida xato. Manzil ham ishlamasa, qoida to'g'ri va yo'l yetishmayotgan bo'lishi mumkin.
Har bir platforma bir xil nom qoidasini qanday ifodalaydi
Maqsad bir xil, maydon nomlari esa unday emas. Bir klientdan boshqasiga ko'chirilgan misol toza tahlil qilinadi va hech qachon mos kelmaydi. Uch shakl shunday ko'rinadi:
| Platform | Where the rule lives | What usually breaks |
|---|---|---|
| Windows | name-resolution policy on the VPN profile | precedence against the interface suffix list |
| Apple platforms | match domains on the DNS settings object | domains attached to the wrong extension |
| Linux | routing domain, split resolver, nsswitch order | the suffix written the wrong way round |
Moslik yoki marshrutlash domeni qo'shimcha testidir, shuning uchun intranet.corp git.intranet.corp ni qamrab oladi va corp.intranet ni qamrab olmaydi, va uni teskari qilish butun konfiguratsiyadagi eng keng tarqalgan xato. Windows xaritani profilga bog'langan nomni hal qilish siyosati sifatida olib yuradi, interfeysda allaqachon mavjud bo'lgan har qanday qo'shimchalar ro'yxatiga qarshi o'z ustuvorlik tartibi bilan. Apple platformalari mos domenlarni tarmoq kengaytmasining DNS sozlamalari obyektiga bog'laydi va tizim ularni har bir cheklangan hal qiluvchiga qo'llaydi. Bu shakllarning hech biri marshrut emas va hech biri yetib bo'lmaydigan manzilni yetib boriladigan qila olmaydi. Windows nomni hal qilish siyosati ma'lumotnomasi o'sha platforma uchun maydon nomlari va ustuvorlik qoidalarini sanab o'tadi, va ular Apple yoki systemd hujjatlari ishlatadigan qoidalar emas.
To'g'ri javobga hamon yo'l kerak
Hal qiluvchining javobi faqat manzil, va dastur hali ham unga yetib borishi kerak. Bo'lingan tunnel dizayni ko'pincha 10.20.0.0/16 ni itaradi va standart marshrutni ushlab turadi, shuning uchun ichki nom hal bo'ladi va keyin aloqa osilib qoladi. Qarama-qarshi holat ham shunchalik keng tarqalgan: marshrut bor, ochiq hal qiluvchi shaxsiy nomga NXDOMAIN bilan javob beradi va nosozlik marshrutlash muammosi sifatida qayd etiladi. Avval yo'lni tekshirish sizni hech qachon hal bo'lmaydigan nom uchun marshrutlarga qaratib qo'yadi.
Ikkala yarim ham qamrab olmaydigan uchinchi darvoza ham bor. Shlyuzdagi ACL, xavfsizlik devori qoidasi yoki klient tomonidagi siyosat ikkala qaror to'g'ri bo'lganidan keyin ham aloqani tashlab yuborishi mumkin. Nom hal bo'lsa, marshrut bor bo'lsa va aloqa hamon vaqt tugatsa, DNS ni tekshirishni to'xtating.
Nomlar va yo'llarni qat'iy tartibda tekshirish
Tartib tanlang va unga amal qiling, aks holda oxirgi marta muvaffaqiyatsiz bo'lgan qadamni ta'qib qilasiz. Hujjatlashtirilgan to'liq ichki nomni hal qiling, javob marshrut jadvali ko'tara oladigan manzil ekanini tasdiqlang, so'ng ochiq nom bilan takrorlang va tunnel hamma narsani ushlamaganini isbotlang. systemd xostida so'rov va hal qiluvchining marshrutlash domeni bir buyruq masofasida:
resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10Windows klienti xuddi shu ikki savolni boshqa cmdlet bilan beradi. Ikkinchisi tizim haqiqatda ishlatadigan interfeysni xabar qiladi:
Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10Qidiruv manzil qaytarsa va yo'l tekshiruvi jismoniy interfeysni aytsa, nom qoidasi ishladi, marshrut esa ishlamadi. Qisqa nom muvaffaqiyatsiz bo'lib, to'liq nom hal bo'lsa, qo'shimchalar ro'yxati xato, hal qiluvchi emas.
Taqqoslash odatda qayerda xato ketadi
Birinchi xato aloqasiz ochiq hal qiluvchidan shaxsiy nom haqida so'rash va rad javobni VPN haqidagi dalil deb o'qish. Ikkinchisi ishlaydigan ochiq qidiruv tunnel hal qiluvchisining yo'lini isbotlaydi deb o'ylash. Uchinchisi bo'lingan tunnel va bo'lingan DNS ni bitta dizayn qarori deb hisoblash, holbuki joriy etish birida to'g'ri, ikkinchisida buzilgan bo'lishi mumkin. Har bir xato ayblanayotgan qismni hech qachon mashq qilmagan testdan ishonchli xulosalar beradi.
O'z xavfsiz DNS iga ega brauzer ham tizim qoidasini chetlab o'tishi mumkin, shuning uchun bir brauzer muvaffaqiyatsiz bo'lib, boshqasi muvaffaqiyatli bo'lishi qarama-qarshilik emas. Javob bergan hal qiluvchini taqqoslang, shikoyat qilgan brauzerni emas.
Ikkala yarim ko'rinib qolgach, qolgan savol texnik emas, siyosiy savol: qaysi nom fazolari tashkilotga tegishli, har bir javobning egasi kim va ularning qaysilari mashinadan butunlay chiqishi kerak. Buni profil yoniga yozib qo'ying, chunki qoidaga keyingi tegadigan odamga bu kerak bo'ladi.