Windowsda OpenVPN adapteri tinmay uzilib ulanmoqdami? IP manzilning takrorlanishini tekshiring
Windows adaptori tinmay uzilib ulanishi ko'pincha drayver xatosi emas, manzil to'qnashuvidir. 4198 va 4199 hodisalarini o'qing, manzilning ikkinchi egasini toping, so'ng noyob manzillarni mahkamlang.
Windowsda manzilni olib, uni tashlab yuboradigan va buni har bir necha soniyada takrorlaydigan OpenVPN adaptori odatda DHCP xatosi emas. Adapterga boshqa narsa allaqachon javob berayotgan manzilni ishlatish aytilmoqda, shuning uchun Windows uni yaroqsiz deb belgilaydi va klient boshidan boshlaydi. Klient jurnali jim turadi, chunki to'qnashuv undan pastda, operatsion tizimning o'z tarmoq stackida hal qilinadi.
Bu farq muhim, chunki tunnel konfiguratsiyasiga qaratilgan har bir tuzatish qadami server tomonidagi takrorlangan manzilni o'tkazib yuboradi.
Klient jurnalidan emas, Windows hodisalar jurnalidan boshlang
Windows manzil to'qnashuvlarini System jurnalida 4198 va 4199 hodisa identifikatorlari bilan yozadi. Birinchisi manzil uchun aniqlangan to'qnashuv haqida xabar beradi, ikkinchisi interfeys o'zi sozlangan manzildan foydalana olmaganini aytadi. Hech biri OpenVPNni tilga olmaydi, shuning uchun ularni e'tibordan chetda qoldirish oson.
Yaqin hodisalarni chiqaring va ularning vaqt belgilarini adapterning yangilanish davri bilan solishtiring: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. Har o'n besh soniyada to'qnashuv bo'lishi, o'sha manzilga doimo javob berayotgan egasiga qarshi uni qayta urinayotgan klientga mos keladi. Ulanish paytida bitta to'qnashuv esa bir martalik to'qnashuvga ishora qiladi. Qanday bo'lmasin, keyingi savol — bu manzil yana kimda.
Uchta tartib ikki hostni bitta manzilga qo'yadi
Serverdan manzil kimda deb o'ylashini so'rang, so'ng tarmoqdan unga kim javob berishini so'rang. grep -H ifconfig-push /etc/openvpn/ccd/* har bir mahkamlangan tunnel manzilini va u tegishli sertifikatni sanab chiqadi. ip -4 neigh show dev tap0 ko'prik ikkinchi qatlamda nimani o'rganganini ko'rsatadi. Bu ikki ro'yxatni solishtirish ko'p takrorlarni bir daqiqadan kamroq vaqt ichida topadi.
Uchta tartib ularning deyarli barchasini tushuntiradi: client-config-dir yozuvi ikkita sertifikat uchun bitta manzilni mahkamlaydi, ko'prikli tap segmenti mashinaga boshqa hostda allaqachon statik bo'lgan manzilni beradi yoki eskirgan ijara fayli hali ulangan klient o'ziniki deb bilgan manzilni qaytaradi. Uchinchi holat eng ayyor, chunki ifconfig-pool-persist ma'lum klientlar uchun manzillarni ataylab qayta ishlatadi.
Manzil uchun poyga qilish o'rniga uni noyob qiling
Yuklanish tartibi faqat bugun kim yutishini hal qiladi, shuning uchun qayta ishga tushirish ketma-ketligiga asoslangan har qanday yechimni vaqtinchalik deb hisoblang. Har bir klientga o'zining ifconfig-push satrini bering yoki hech qanday ko'prik yoki server interfeysi tegmaydigan diapazondan statik manzillar ajrating. Klientlar ro'yxatini umumiy nomlarning takrorlari bo'yicha ham tekshiring, chunki duplicate-cn ikki sessiyaga bitta identifikatsiyani va shu sababli bitta mahkamlangan manzilni bo'lishishga imkon beradi. Agar ko'prikli qurilmaga haqiqatan ham qat'iy manzil kerak bo'lsa, uni o'z subnetiga ko'chiring yoki server qayd etadigan joyda pooldan zaxiralang.
persist faylini faqat unda qaysi ijaralar borligini bilganingizdan keyin o'chiring, aks holda keyingi qayta ulanish o'sha manzillarni yana beradi.
To'g'ri tartibda qayta ishga tushiring va har bir manzil uchun bitta ega borligini tasdiqlang
Avval o'zgartirishni serverda qo'llang, so'ng klientlarni qayta ulang, toki har bir ishtirokchi tuzatilgan poolga qarshi ro'yxatdan o'tsin. Klientlarni birinchi bo'lib qayta ishga tushirish ularni server hali band deb biladigan manzillarda qoldiradi. Qayta ishga tushirgandan so'ng holat faylini o'qing va har bir umumiy nom bir marta bitta manzil bilan paydo bo'lishini tasdiqlang. Bitta nom uchun ikkita yozuv eski sessiya hech qachon yopilmaganini bildiradi, pool buzilganini emas.
Agar klient hali ham manzilini ushlab turolmasa, o'sha hostdagi ko'prik interfeysi uni olib yurmayotganini tekshiring. Vendor qurilmasidan manzilni meros olgan ko'prik, VPN server bu manzilni klientga topshirgan bo'lsa ham, unga ARP javobini beradi.
Chiptani yopishdan oldin to'liq yangilanish davridan uzoqroq kuzating
Bitta toza o'qish hech narsani isbotlamaydi. Adapterni kamida o'n daqiqa kuzatib turing va o'rtada qayta ulanishni majburan amalga oshiring: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. Manzil qayta ulanishdan omon o'tishi va afzal holatda qolishi kerak.
Keyin birinchi qadamdagi hodisa so'rovini qayta ishga tushiring va u hech qanday yangilik qaytarmasligini tasdiqlang. Qayta ulanish davomida jim jurnal to'qnashuv yo'qolganining dalilidir, bir marta ulangandan keyingi jim jurnal esa faqat poyga hali sodir bo'lmaganini bildiradi. Nihoyat, tunnel mavjud bo'lgan resursni sinab ko'ring, chunki manzilini yo'qotgan ko'prik VPN o'zi sog'lom ko'rinib turganda ham vendor yo'lini buzishi mumkin.
Pool diapazonini, har bir mahkamlangan manzilni va unga egalik qiluvchi hostni server yozuvlariga yozib qo'ying. Shunda keyingi to'qnashuvni payqash uchun daqiqalar kerak bo'ladi, uni qaytadan topish uchun yarim kun emas.