VPN domen nomi tizimi (DNS) haqiqatan ishlatiladimi? 53-portni ushlang va ko'ring
Surilgan DNS tanlovi so'rov yo'li emas. Interfeys nima saqlayotganini ko'ring, so'rovning chiqishini kuzating va oqish testi sahifasiga dalil sifatida ishonishni to'xtating.
Ko'pchilikdan VPN mijozi DNS bilan nima qiladi deb so'rang, ular hal qiluvchini o'rnatadi, shuning uchun so'rovlar tunnel ichida yuradi deb aytadi. Surish haqiqiy; uning so'rovga aylanishi haqidagi taxmin esa yo'q. Surilgan tanlov va simdagi paket orasida uch bosqich bor va har biri mustaqil ravishda shunday muvaffaqiyatsiz bo'ladiki, hammasi buzilgan DNS serverga o'xshaydi. Shuning uchun oqish testi sahifasi va ishlaydigan brauzer bir lahzada bir mashina haqida kelisha olmasligi mumkin.
Surilgan tanlov so'rov emas
Birinchi bosqich — server sozlamalarni taklif qiladi, masalan tunnel ichidagi hal qiluvchini nomlaydigan surilgan DNS tanlovi. Ikkinchi bosqich — mijoz bu sozlamalarni interfeysga qo'llaydi. Uchinchi bosqich — dastur haqiqatan o'sha manzilga so'rov yuboradi. Ikkinchi bosqichdagi nosozlik tanlovni ulanish jurnalida ko'rinadigan qilib qoldiradi, hal qiluvchilar ro'yxati esa o'zgarmaydi, uchinchi bosqichdagi nosozlik esa butunlay to'g'ri hal qiluvchilar ro'yxatini ishlatilmay qoldiradi.
Nosozliklarni tuzatishning ko'p qismi bu uchtasini birlashtirib, VPN serverini ayblaydi, holbuki odatda o'z ulushini bajarganini isbotlay oladigan yagona tomon shu. Buning o'rniga mijozning haqiqiy hal qiluvchi holatini o'qing, so'ng bitta so'rovning chiqishini kuzating. Bu ikki kuzatuv konfiguratsiyani marshrutlashdan va siyosatdan ajratadi va taxminan besh daqiqa oladi. Tutib olishlarni saqlang, chunki keyingi muhandis ularning tavsifini emas, oldin va keyin holatini xohlaydi.
Interfeys haqiqatan nima saqlayotganini tekshiring
Linuxda tizim hal qiluvchisi oddiy fayl, NetworkManager yoki systemd-resolved bo'lishi mumkin va ularning qaysi biri unga egalik qilishi surilgan server qayerda qo'nishini belgilaydi. Buyruq satridagi OpenVPN jarayoni tizim hal qiluvchisini o'zi yangilamaydi, shuning uchun hujjatlashtirilgan integratsiya up/down skripti yoki sozlamalarni qanday qo'llashni allaqachon biladigan ulanish menejeri. Ikkalasini birga ishga tushirish poyga yaratishning samarali usuli.
resolvectl status
cat /etc/resolv.conf
Windowsda ro'yxat har bir adapter uchun alohida, shuning uchun tunnel adapteri ichki serverlarni saqlab turishi mumkin, jismoniy adapter esa mahalliy serverlarni ushlab, ba'zi nomlar uchun g'alaba qozonadi. Faol deb o'ylagan adapteringizni emas, ikkalasini solishtiring.
Bitta so'rovni mashinadan tashqariga kuzatib boring
Ikkala interfeysni bir vaqtda tutib oling, so'ng ichki hal qiluvchidan foydalanishi kerak bo'lgan bitta nomni hal qiling. O'sha juft tutib olish hech bir konfiguratsiya chiqishi javob bera olmaydigan narsaga javob beradi.
sudo tcpdump -ni tun0 port 53
sudo tcpdump -ni any port 53
Jismoniy interfeysda paydo bo'lib, tunnelda hech qachon ko'rinmaydigan so'rov mijoz noto'g'ri hal qiluvchini tanlaganini bildiradi. Ikkalasida ham ko'rinmaydigan so'rov esa dastur keshdan javob berganini, loopbackda tinglayotgan stubdan so'raganini yoki trafigi hech qachon 53-port sifatida ko'rinmaydigan shifrlangan hal qiluvchi ishlatganini bildiradi. Faqat so'rovlarni emas, javoblarni ham tutib oling, chunki tunneldan chiqqan so'rovga ochiq manzildan javob kelishi javobning umuman kelmasligidan boshqa nosozlik.
Faqat o'z DNS ini qabul qiladigan tarmoq devori
Tijorat mijozlari ba'zan o'z filtr zanjirlarini o'rnatadi. Hujjatlashtirilgan bir andoza DNS ga mijozning o'z hal qiluvchisiga ruxsat beradi va loopback bo'lmagan interfeysdan chiqmoqchi bo'lgan qolgan barcha UDP 53-port trafigini tashlaydi, foydalanuvchi ataylab boshqa joyga yo'naltirgan trafik ham shu jumladan. Demon so'rovlari izsiz yo'qoladi, bu esa filtr emas, hal qiluvchi nosozligi sifatida o'qiladi.
sudo iptables -S OUTPUT
sudo iptables -S | grep -i -E 'dns|53'
Agar tashlash qoidasi sizning istisnodan oldin baholansa, qo'shilgan qoidaga hech qachon yetilmaydi, shuning uchun uni birinchi o'ringa qo'ying va manzilni haqiqatan nazarda tutgan hal qiluvchi bilan cheklang.
sudo iptables -I OUTPUT 1 -p udp --dport 53 -d 172.20.8.1 -j ACCEPT
Bu istisno siyosat emas, diagnostika. Agar yetkazib beruvchi qoidasi ataylab bo'lsa, qo'llab-quvvatlanadigan tuzatish mijozni o'sha hal qiluvchiga ruxsat beradigan qilib sozlash va qarorni yozib qo'yishdir, chunki kiritilgan qoida keyingi mijoz yangilanishidan omon qolmaydi.
Nega oqish sahifasi ko'ringandan kamroq isbotlaydi
Oqish testi sahifasi ko'rsatadigan narsa test operatori bilan gaplashgan hal qiluvchi, sizning mashinangiz murojaat qilgani emas. Tashqariga rekursiya qiladigan mahalliy uzatuvchi o'z chiqish manzilini o'sha sahifaga qo'yadi va shifrlangan so'rovlar sahifani butunlay bo'sh qoldirishi mumkin. Ikkala natija ham noto'g'ri o'qiladi, biri oqish, ikkinchisi kafolat sifatida va hech bir o'qish kuzatuvdan kelib chiqmaydi.
Himoya qilinadigan dalil tutib olishdir: interfeys, manzil, javob va vaqt belgisi. Tunnel ko'tarilishidan oldin bittasini, keyin bittasini oling va keyingi safar nom muvaffaqiyatsiz bo'lganda ularni solishtiring. Bu juft keyingi odamga nosozlik hal qilishda, marshrutlashda yoki hal qiluvchining o'z kirish siyosatida bo'lganini ham aytadi.