Nega nc -uz OpenVPN serveri tayyor ekanini isbotlay olmaydi

Ishga tushirish nc -uz OpenVPN serveriga qarshi deyarli hech narsani o’lchamaydi, va OpenBSD qo’llanmasi buni o’z ogohlantirishlarida aytadi: bu rejimdagi UDP skanerlari biror narsa tinglayotganidan qat’i nazar muvaffaqiyat haqida xabar beradi. Chiqish holati masofadagi holatni emas, mahalliy yuborishni aks ettiradi, shuning uchun unga ishonadigan nazoratchi jarayonlar jadvali ishonchli ko’ringancha o’lik serverni sog’lom deb belgilab turadi. Uni almashtirish tekshiruv qaysi savolga javob berishi kerakligini hal qilishdan boshlanadi, chunki jarayon, tinglovchi, autentifikatsiya va ilovaning yetib borilishi to’rt xil kuzatuvdir. Ulardan birini nomlaydigan tekshiruv foydali; to’rttasini ham nazarda tutadigan tekshiruv yukdir.

UDP tekshiruvi nimani kuzata oladi va nimani kuzata olmaydi

nc -uz datagramma yuboradi va chiqadi, qaytargan holat esa mahalliy yuborishni tasvirlaydi. Yopiq port ICMP port unreachable bilan javob berishi mumkin, lekin bu skanerlash rejimining hujjatlashtirilgan xatti-harakati buni muvaffaqiyatsizlikka aylantirmaydi, filtrlangan port esa umuman javob bermaydi. Shuning uchun sukunat va muvaffaqiyat chaqiruvchi uchun bir xil ma’noni bildiradi.

Bu tekshiruvni serverning emas, mahalliy stekning sinoviga aylantiradi. U xostning yetib borilishini, portning bog’langanini, OpenVPN jarayonining ishlayotganini yoki mijoz autentifikatsiyadan o’ta olishini aniqlab bermaydi. TCP ulanish sinovi kuchliroq, chunki qo’l berib ko’rishish aniq javob beradi, lekin faqat joylashtirish haqiqatan TCP da tinglaganda. Tekshiruvni o’sha raqamda TCP ga o’tkazish mavjud bo’lmasligi mumkin tinglovchini sinaydi, faqat UDP li serverga qarshi esa u sog’lom xizmatni ishdan chiqaradi.

Tekshiruvni sozlangan transportga moslashtirish ikkala natijadan biriga ishonishdan oldin keladi. UDP joylashtirish boshqa signal talab qiladi, boshqa protokol emas.

Uchta chaqiruvchi, uchta boshqa savol

Tayyorlik kim so’rayotganiga bog’liq. Yiqilgan jarayonni qayta ishga tushiruvchi xizmat menejeri nusxa ishga tushganini va tinglovchisini bog’laganini bilishi kerak. Yuk balanslagichi hozir kelayotgan mijoz qabul qilinishini bilishi kerak. Monitoring tizimi haqiqiy tarmoqdan kelayotgan yo’l hali ham ruxsat etilgan resursga sessiya olib borishini bilishi kerak.

Bular bir xil tekshiruv emas va bitta tekshiruv uchtasini ham halol qamrab olmaydi. Avval chaqiruvchini tanlang, keyin dalilni.

Tekshiruvni joriy nusxadan quring

OpenVPN nusxa ishga tushishni tugatganda boshlash satrini yozadi va bu satr mahalliy ishga tushish haqida foydali dalildir. Uni joriy ishga tushishdan o’qing, qo’shilayotgan faylning oxiridan emas, chunki o’tgan haftadagi muvaffaqiyat bir daqiqa oldingi muvaffaqiyat kabi o’qiladi. Server har qanday mijoz hech qachon ulanmasidan oldin ham ishga tushishni tugatishi mumkin, shuning uchun satr autentifikatsiya haqida hech narsa demaydi.

Ishga tushish tekshiruvi uchun jarayon holatini joriy jurnal dalili va sozlangan transportga mos tinglovchi bilan juftlang. Jarayon ishlab turib ishga tushishni tugatmagan bo’lsa, tekshiruv muvaffaqiyatsiz bo’lishi kerak, ya’ni jurnal so’rovi shu yuklash va shu birlik bilan cheklanishi lozim.

systemctl is-active openvpn@server
sudo journalctl -u openvpn@server -b --no-pager | grep "Initialization Sequence Completed"
ss -lunp | grep 1194

Uchta chiqish, uchta da’vo: birlik faol, bu yuklash boshlash satrini yaratdi va nimadir UDP portni ushlab turibdi. Ularning hech biri mijoz ulanishi mumkinligini aytmaydi. Ularni holat sahifasida alohida saqlang, hodisa bitta yashil nuqtaga qulab tushmasin.

Uni ataylab buzing va tekshiruvni kuzating

Tekshiruv faqat uning muvaffaqiyatsizligini ko’rganingizdan keyin ishonchli bo’ladi. Serverni to’xtating, tekshiruvni ishga tushiring va kutilgan natijani tasdiqlang. Keyin uni qayta ishga tushiring va tekshiruv boshqa hech qanday o’zgarishsiz tiklanishini tasdiqlang.

sudo systemctl stop openvpn@server
nc -uz 203.0.113.10 1194; echo "exit=$?"
ss -lunp | grep 1194
sudo systemctl start openvpn@server
ss -lunp | grep 1194

Blokni satrma-satr o’qing. netcat buyrug’i exit=0 deb chiqaradi, ammo hech narsa bog’lanmagan, va bir satrdagi butun muammo shu. Birinchi ss hech narsa chiqarmaydi, qayta ishga tushirish muvaffaqiyatli bo’ladi, ikkinchisi esa ss yana tinglovchini ko’rsatadi. Agar tekshiruvingiz to’xtatilgan serverga qarshi o’tsa, u mahalliy stekni o’lchaydi, boshqa hech narsani emas.

Qarama-qarshi muvaffaqiyatsizlik ham muhim. Sog’lom serverga qarshi muvaffaqiyatsiz bo’lgan tekshiruv hech qachon kerak bo’lmagan qayta ishga tushirishlarni keltirib chiqaradi, qayta ishga tushirish sikli esa o’zi uzilishdir. Tekshiruvni unga ko’ra harakat qila oladigan narsaga ulashdan oldin ikkala yo’nalishni sinab ko’ring.

Holat satri nima deyishi kerak

Har bir tekshiruv qaysi chegarani qamrab olishini yozib qo’ying: jarayon, tinglovchi, autentifikatsiya yoki ilova. Bitta tekshiruv kamdan-kam hollarda birdan ko’proq narsani qamrab oladi, ularni “up” ga siqib qo’yadigan holat sahifasi esa hodisa paytida muhim bo’lgan farqni yashiradi. Tarmoq yo’li uchun maxsus identifikatsiyaga ega haqiqiy mijozdan foydalaning, unga qo’l berib ko’rishish va bitta zararsiz ruxsat etilgan amalni tugatishga ruxsat bering, so’ng uzib qo’ying. Bu bir qadamda boshqaruv kanalini, autentifikatsiya siyosatini va tinglovchini mashq qildiradi.

Bu identifikatsiyani haqiqiy foydalanuvchilardan alohida saqlang va unga tekshiruvga kerak bo’lgan eng kam ruxsatlarni bering. Keng kirishga ega tayyorlik tekshiruvi qulaylik uchun qo’shilgan yangi hujum yuzasidir. Uning hisob ma’lumotlarini har qanday boshqa hisob kabi almashtiring, chunki autentifikatsiyani to’xtatgan tekshiruv mijozlarni qabul qilishni to’xtatgan serverga aynan o’xshaydi.

Ogohlantirish matnida chegarani nomlang, birinchi javob beruvchi birlik, soket, sertifikat yoki marshrutga qarash kerakligini bilsin. Nima isbotlaganini ayta olmaydigan tekshiruvga noto’g’ri sabab bilan ishoniladi va netcat tekshiruvi eng avvalo shu tarzda omon qoldi.