Ichki nomlar VPN orqali ochilmaydi, ommaviy saytlar esa ishlaydi

Bir foydalanuvchi intranet xost nomi VPN orqali hal qilinmasligini xabar qiladi. Xuddi shu noutbukdan kelgan ikkinchi xabar oqish testi hali ham so‘rovlarga mahalliy rezolver javob berayotganini ko‘rsatishini aytadi. Ular bitta muammoga o‘xshaydi, lekin ikkita; dalillari boshqacha va birinchisining odatdagi tuzatishi ikkinchisini yanada yomonlashtiradi. Biror sozlamaga tegishdan oldin ularni ajrating.

Bitta nosozlik bo‘lmagan ikki alomat

Ichki nomni hal qila olmaslik savol javobi yo‘q joyga ketganini bildiradi. So‘rovlarning tunneldan chiqishi esa javob mavjud bo‘lsa ham savol noto‘g‘ri joyga ketganini bildiradi. Bular qarama-qarshi nosozliklar: birida javob yetishmaydi, ikkinchisida ortiqcha manzil bor.

Tuzoq shundaki, ofis rezolverini hamma joyga qo‘shish birinchisini tuzatadi va ikkinchisini kafolatlaydi. Ommaviy rezolverni hamma joyga qo‘shish buning aksini qiladi.

Ikkala kuzatuvni vaqt belgisi bilan yozib oling, so‘ng quyidagi to‘rtta tekshiruvni tartib bilan bajaring.

So‘rovni qaysi adapterning rezolveri oladi

Windows’da DNS mijozi serverlarni adapter bog‘lanish tartibiga ko‘ra tanlaydi va tunnel adapteri avtomatik ravishda birinchi bo‘lmaydi. Adapterning kengaytirilgan sozlamalarini oching, masofaviy ulanishni jismoniy adapterdan yuqoriga ko‘chiring, so‘ng qayta ulanib, o‘zgarish yangi sessiyada qo‘llanishini ta’minlang.

Bog‘lanish tartibi faqat birinchi yarmi. Mijoz qaysi nomlar shu adapterga tegishli ekanini ham bilishi kerak, bu esa tartib emas, suffiks masalasidir.

Ishlayotgan mashinaning ipconfig /all natijasini noutbukniki bilan yonma-yon qo‘ying, ikkalasi ham tunnel ko‘tarilgan paytda olingan bo‘lsin. Ishlayotgan mashina ofis adapterida ulanishga xos DNS suffiksini ko‘rsatadi, noutbuk esa tunnelda hech narsa ko‘rsatmasligi mumkin. Bu farq “server shu yerda, nom esa baribir hal bo‘lmayapti” tipidagi xabarlarning butun bir sinfini tushuntiradi, chunki suffikssiz qisqa nom ofis rezolveri xizmat qiladigan zonaga hech qachon to‘ldirilmaydi.

Qisqa nomga marshrutdan oldin suffiks kerak

Saralanmagan xost nomini yozish rezolverdan domenni taxmin qilishni so‘raydi. Taxmin ulanishga biriktirilgan suffikslar ro‘yxatidan olinadi va agar bu ro‘yxat bo‘sh bo‘lsa, so‘rov hech qaysi xususiy zonaga mos kelmaydigan bitta yorliq sifatida chiqadi.

Ishlayotgan mashinaning suffiksini DNS yorlig‘idagi VPN adapterining IPv4 xossalariga ko‘chiring, so‘ng qayta ulaning. Linux’da buning ekvivalenti tunnel havolasidagi qidiruv domeni bo‘lib, systemd-resolved uni global emas, har bir havola uchun ko‘rsatadi.

Ikki sozlamani qaydlaringizda alohida saqlang. Suffiks nima so‘ralishini o‘zgartiradi; rezolver manzili kimdan so‘ralishini o‘zgartiradi. Biri xato bo‘lganda ikkinchisini tuzatish tasodifiy ko‘rinadigan natija beradi.

Avval rezolverdan, keyin nomdan so‘rang

Ofis rezolveriga to‘g‘ridan-to‘g‘ri so‘rov nom muammosini yo‘l muammosidan ajratadi, chunki u mijozning rezolver tanlovini butunlay chetlab o‘tadi.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

Birinchi buyruq aniq serverdan to‘liq malakali nomni so‘raydi. Agar u javob bersa, rezolver va unga boradigan yo‘l joyida, nosozlik tanlov yoki suffiksda. Agar vaqt tugasa, manzil xato yoki yetib bo‘lmaydigan joyda va muammo DNS emas, marshrutlashda. Ikkinchi buyruq qisqa nom bilan nima bo‘lishini ko‘rsatadi, uchinchisi esa systemd ishlayotgan xostda har bir havola uchun rezolver konfiguratsiyasini chiqaradi.

Ba’zi tarmoqlar noma’lum nomlar uchun qaytaradigan joker javoblarga e’tibor bering. Ishonchli ko‘rinadigan javob mo‘ljallangan server javob berganining isboti emas, shuning uchun qaytgan manzilni ichki xizmat aslida ishlatadigan manzil bilan solishtiring. Agar manzil to‘xtash sahifasiga yoki proksiga tegishli bo‘lsa, rezolver javob berdi, lekin javob hech qachon sizniki bo‘lmagan. Bu farq boshidan ishlab turgan tunnel ortidan quvishning bir soatini tejaydi.

Linux’da /etc/resolv.conf faylini qayta yozadigan VPN mijozi mahalliy rezolverlarni butunlay almashtiradi. vpnc buni to‘xtatish uchun DNSUpdate no parametrini taqdim etadi va systemd-resolved faqat ro‘yxatdagi domenlarni tunnel havolasiga yo‘naltira oladi. Ikkala yondashuv ham ommaviy nomlarni mahalliy rezolverda saqlab, ichki nomlarni ofisga yuboradi.

Oqish — bu katakcha emas, qoida

Nom hal qilish 53-portga UDP almashinuvidir, shuning uchun veb-trafikni tashib, UDPni tashimaydigan tunnel so‘rovni jismoniy yo‘lda qoldiradi. Buni ommaviy nom hal qilinayotganda jismoniy tarmoq kartasida ushlash orqali isbotlang. O‘sha interfeysda o‘qiladigan shaklda ko‘ringan so‘rov tunnel uni tashimayotganini bildiradi.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

Agar so‘rov o‘sha interfeysda o‘qiladigan shaklda ko‘rinsa, tunnel uni tashimayapti. Tuzatish — 53-portga faqat VPN yuborgan rezolverga ruxsat berib, boshqa manzillarni tashlab yuboradigan qoida, shuningdek yuborilgan parametrni indamay tashlab yubormaydigan mijoz konfiguratsiyasi.

Bu oxirgi qism ko‘ringanidan muhimroq. OpenVPN’ni route-nopull bilan ishga tushirsangiz, yuborilgan DNS parametri marshrutlar bilan birga yo‘qoladi, agar tortish filtrini uni saqlab qolish uchun kengaytirmasangiz. Va dhcp-option DNS ni e’tiborsiz qoldiradigan mijoz avval nima ishlatgan bo‘lsa, shuni ishlatishda davom etadi. Server tomonidagi har qanday o‘zgarish yangi sessiyani talab qiladi, chunki rezolverlar ro‘yxati tunnel ko‘tarilganda yetkaziladi va eski sessiya eski holatni ko‘rsatishda davom etadi.

Chiptani yopishdan oldin qaysi nosozlikni haqiqatan kuzatganingizni yozib qo‘ying. Ichki javobning yo‘qligi va tunneldan qochayotgan so‘rov turli tuzatishlarni talab qiladi, birinchisini tuzatadigan suffiks o‘zgarishi ikkinchisini sekingina yomonlashtirishi mumkin. Chiptani keyingi olgan kishi yorliqqa ishonadi, shuning uchun yorliqni aniq qiling.