53-portdagi OpenVPN: odamlar chalkashtiradigan uch suhbat
Endpoint nomini hal qilish, shifrlangan uzatish va tunneldan keyingi DNS — bu uch xil suhbat. Port yoki rezolverni almashtirishdan oldin qaysi bosqichda xato bo'lganini aniqlang.
VPN 53-portda bloklangan degan xabarlar turli sabablarga ko'ra muvaffaqiyatsiz bo'ladigan uch kuzatuvni aralashtiradi. Endpoint nomini hal qilish har qanday tunnel paydo bo'lishidan oldin sodir bo'ladi, shifrlangan uzatish alohida suhbat, undan keyin qilinadigan DNS so'rovlari esa uchinchisi. Har birining o'z muvaffaqiyatsizlik belgisi bor va ulardan faqat bittasi DNS bilan bog'liq.
Biron narsani o'zgartirishdan oldin paketlarni maqsadi bo'yicha ajrating, chunki tuzatish bosqichga ergashadi.
Uch suhbat, bitta port raqami
Birinchi suhbat — endpoint uchun nom qidiruvi: mashinangiz sozlangan rezolverdan vpn.example.com qayerda ekanini so'raydi va bu javob oddiy DNS orqali, mijoz bitta ham tunnel paketini yuborishidan oldin keladi. Ikkinchisi — OpenVPN uzatishining o'zi, u qidiruv bergan manzilga profil ko'rsatgan protokol va portda ulanadi. Uchinchisi tunnel ko'tarilgandan keyin sodir bo'ladi, ilovalar nom so'raganda va yuborilgan rezolver sozlamalari kim javob berishini hal qiladi.
Bu uchtasi mustaqil ravishda muvaffaqiyatli yoki muvaffaqiyatsiz bo'lishi mumkin. Mijoz o'z endpointini mukammal hal qilib, baribir tinglovchiga yetib bormasligi mumkin, va DNS sozlamalari hech qachon kelmaganligi sababli har bir ichki nom qidiruvi muvaffaqiyatsiz bo'layotganda tunnel o'rnatishi mumkin.
| Conversation | When it happens | What has to be true |
|---|---|---|
| Endpoint lookup | Before the client contacts a hostname | An underlying resolver path can answer for the endpoint name |
| OpenVPN transport | During tunnel establishment | The gateway listens on its configured transport, address and port, and nothing filters it |
| Application DNS | During or after the protected session | A resolver the client can reach, plus routing that carries its queries |
Jadvalni tavsif emas, tekshiruv ro'yxati sifatida o'qing. Agar endpoint nomi hal qilinmasa, keyin hech narsa ishlay olmaydi va tunnel hech qachon boshlanmaydi.
Port raqami ilovani nomlamaydi
53-port odat bo'yicha DNS tashiydi va OpenVPN operatori u yerda tinglovchini ham e'lon qilishi mumkin, shuning uchun bu raqam yomon identifikator. UDP 53 dagi OpenVPN sessiyasi baribir OpenVPN sessiyasi, 53-portdagi serverga yuborilgan DNS so'rovi esa tunnelga ruxsat berilganini aytmaydi. Profilning proto va remote satrlari tashqi endpointni belgilaydi; port raqamining o'zi hech narsani belgilamaydi.
Diagnostikada bu ikki tomonga ham ishlaydi: 53-portga umumiy UDP sinovi port javob berishini isbotlaydi, VPN xizmati javob berishini emas. Haqiqiy mijoz va haqiqiy profil bilan sinab ko'ring, chunki xizmat kutgan qo'l siqishni faqat shu mashq qildiradi.
Tarmoqni ayblashdan oldin tinglovchini isbotlang
Serverda ss -lunp | grep 53 bilan nima bog'langanini tekshiring va profil protokoli hamda porti bilan solishtiring. Mijoz tarmog'idan mijozni batafsilroq rejimda ishga tushiring, shunda jurnal qaysi manzil va uzatishni sinab ko'rganini ko'rsatadi. Agar server tinglayotgan bo'lsa-yu, mijoz paketlari yetib kelmasa, ularni yo'l yoki siyosat rad etmoqda, va bu tarmoq egasi bilan suhbat, portni almashtirishga sabab emas.
Boshqa port faqat xizmat haqiqatan u yerda tinglayotganda va joylashtirish ruxsat berganida yordam beradi. Boshqariladigan tarmoq filtratsiyasidan qochish uchun tinglovchini ko'chirish — siyosat qarori, muammoni hal qilish bosqichi emas. Xizmatni o'zgartirishdan oldin tarmoq egasidan nima ruxsat etilganini so'rang, chunki siyosatni buzadigan aylanma yo'l baribir keyinroq yopiladi. O'sha javobni profil yoniga yozib qo'ying, keyingi odam so'rovni takrorlamasin.
Tunneldan keyin DNSni alohida tekshiring
Tunnel ko'tarilgach, VPN interfeysidagi rezolver holatini ko'rib chiqing va bitta ichki hamda bitta ommaviy nomni so'rang. Agar tunnel trafik tashiayotganda ichki nomlar muvaffaqiyatsiz bo'lsa, yuborilgan DNS sozlamalari qo'llanilmagan, bu uzatish emas, mijoz integratsiyasi masalasi. Agar ommaviy nomlar muvaffaqiyatsiz bo'lib, ichki nomlar ishlasa, bo'lingan tunnel siyosati o'ziga sozlangan ishni qilmoqda.
DNS o'zgarishlarini rezolver egasida qoldiring. Bitta sinovdan o'tish uchun boshqariladigan rezolver konfiguratsiyasini qayta yozish mashinadagi qolgan hamma narsa uchun shaxsiy nomlarni buzishi mumkin. Agar tunnel rezolver yuborsa va mijoz uni e'tiborsiz qoldirsa, boshqa joyga statik yozuv qo'shish o'rniga mijoz integratsiyasini tuzating. Statik yozuvlar muvaffaqiyatsizlikni kimdir tarmoqni almashtirgunga qadar yashiradi. Qaysi rezolver qaysi nom maydoniga javob berishi kerakligini yozib qo'ying.