1194-port allaqachon band: bu OpenVPN soketi kimniki?

Xuddi shu server profilini ikki marta ishga tushiring va ikkinchi jarayon 1194-port uchun manzil allaqachon band xatosi bilan chiqadi. Odatiy holatda konfliktni diagnostik ishga tushirish yaratgan, asl nusxa esa mijozlarga hali ham to‘liq xizmat ko‘rsatib turibdi. Bu hikoya ushbu hisobotlarning katta qismini tushuntiradi va biror narsani qayta ishga tushirishdan oldin uni tanib olishga arziydi. Bu hal qilishning eng arzon varianti ham.

Xato mahalliy ulanishni tavsiflaydi va undan boshqa hech narsani emas. Bu provayder portni bloklayotgani, mijoz noto‘g‘ri parol yuborgani yoki sertifikatlar zanjiri buzilgani uchun dalil emas.

Aniq ulanish xatosini o‘qing

Bu oiladagi ikki xato har xil ma’noni bildiradi va ularni aralashtirish sizni noto‘g‘ri qatlamga yuboradi. „Manzil allaqachon band“ degani boshqa soket siz so‘ragan oxirgi nuqtani ushlab turibdi. „Manzil mavjud emas“ degani so‘ralgan manzil bu xostda hali yo‘q, bu tayyorlik muammosi, nusxa emas.

systemctl status openvpn-server@lab --no-pager
journalctl -u openvpn-server@lab -n 20 --no-pager

Biror narsani o‘zgartirishdan oldin xato matnini nusxalang, unda ko‘rsatilgan manzil va port bilan birga. Interfeys paydo bo‘lishini kutayotgan xizmat ikkinchi xatoni qayta-qayta qayd etadi, so‘ng manzil mavjud bo‘lganda muvaffaqiyatli ulanadi; birinchi xatoni qayd etuvchi xizmat nusxa hal qilinmaguncha hech qachon muvaffaqiyatga erishmaydi. Qaysi birini ko‘rganingizni yozib qo‘yish hech narsaga turmaydi va behuda interfeys qidiruvini tejaydi.

Soketni inventarizatsiya qiling, portni emas

Port raqami to‘liq bo‘lmagan inventar. Oxirgi nuqta — transport, manzil oilasi, mahalliy manzil va port, hammasi bitta tarmoq nom maydoni ichida. Bitta raqamdagi UDP tinglovchisi va TCP tinglovchisi alohida soketlar, turli nom maydonlaridagi bitta raqamdagi ikki jarayon hech qachon uchrashmaydi.

ss -lunp | grep -F ':1194'
ss -ltnp | grep -F ':1194'
ss -lunp 'sport = :1194'

Avval profil haqiqatda ishlatadigan transportni ishga tushiring. Keyin faqat raqamga emas, mahalliy manzil ustuniga qarang: wildcard ulanish har bir mahalliy manzilni qamrab oladi, shuning uchun bitta aniq manzilni so‘rayotgan ikkinchi jarayon chop etilgan satrlar boshqacha bo‘lsa ham u bilan to‘qnashishi mumkin. Soketni qayta ishlatish parametrlari va platforma qoidalari aniq natijani belgilaydi, shuning uchun bu har bir joylashtirishda qo‘llanadigan qoida emas, kuzatuv bo‘lishi kerak.

Uni qaysi jarayon egalik qilishini aniqlang

Raqamli oxirgi nuqtalar va jarayon ma’lumoti sizning imtiyozlaringiz ruxsat berganda egasini aniqlaydi va sizga kerak bo‘lgan narsa egasi, dastur nomi emas. Ikki OpenVPN jarayoni turli profillarni ishga tushirishi mumkin, tinglovchini ushlab turgan jarayon esa siz eng kam kutgan jarayon bo‘lishi mumkin.

sudo ss -lunp 'sport = :1194'
sudo fuser -v -n udp 1194

Topganingizni xizmat menejeri, konteyner ish muhiti yoki oldingi sinovdan qolgan terminal jarayoni bilan taqqoslang. Jarayon tafsilotlarining yo‘qligi soketning egasi yo‘qligiga dalil emas; odatda bu so‘rov yetarli ruxsatsiz bajarilganini bildiradi. Xuddi shunday, faqat TCP ro‘yxati UDP konfliktini bartaraf etmaydi, shuning uchun xatoda nomlangan transportni tekshiring. Faqat jarayon nomi qaysi profil yuklanganini hech qachon aytmaydi va aynan profil oxirgi nuqtani belgilaydi.

Bitta egasi yoki ikkita loyihalangan nusxa

Agar joylashtirish bitta serverni nazarda tutsa, bitta hayot sikli egasini saqlang va uni kuzatish uchun ikkinchi nusxani ishga tushirish o‘rniga o‘sha nusxaning jurnalini yoki sozlangan logini o‘qing. Boshqariladigan old planda ishlash haqiqatan zarur bo‘lganda, boshqarilayotgan nusxani ataylab to‘xtating va buni qilishdan oldin u xizmat ko‘rsatayotgan mijozlarni hisobga oling.

Agar ikkita nusxa nazarda tutilsa, ularga alohida tinglovchilar va qolgan hamma narsani alohida bering: manzil hovuzlari, virtual interfeyslar, marshrutlash siyosati va konfiguratsiya egaligi. Faqat boshqa port soketdan boshqa hech narsani ajratmaydi, ikki server esa baribir bitta hovuz va bir xil marshrutlar uchun kurashadi.

Uchta qisqa yo‘lni nomlashga arziydi, chunki ular bu xato haqidagi har bir muhokamada uchraydi. Aybdorga o‘xshagan tasodifiy PIDni o‘ldirmang. Xabarni jim qilish uchun soketni birgalikda ishlatishni yoqmang. Server profilini mijoz uslubidagi bog‘lanmagan konfiguratsiyaga almashtirmang, chunki bu ulanish xatosini yo‘q qiladi; server asl konfliktga qaraganda diagnostika qilish qiyinroq tarzda yetib bo‘lmaydigan bo‘lib qoladi.

Portni o‘zgartirish faqat yangi tinglovchi tasdiqlangan loyihaning bir qismi bo‘lganda, qayta yo‘naltirish qoidasi va mijozning oxirgi nuqtasi bilan birga qonuniy javob bo‘ladi. Agar ular yangilanmagan bo‘lsa, siz konfliktni hech kim topa olmaydigan joyga ko‘chirdingiz.

Hamma narsadan oldin ulanishni tekshiring

Cheklangan tuzatishdan so‘ng, mo‘ljallangan nusxa faol ekanini, uning tinglovchisi kutilgan transportda ko‘rinishini va mijoz ulanishi mumkinligini tasdiqlang. Muvaffaqiyatli ulanish faqat mahalliy soket bosqichini yakunlaydi; tunnel ko‘tarilgandan keyin autentifikatsiya yoki trafik haqida hech narsani tasdiqlamaydi.

ss -lunp 'sport = :1194'
systemctl is-active openvpn-server@lab
journalctl -u openvpn-server@lab -f

Agar soket mavjud bo‘lsa-yu, mijoz hali ham muvaffaqiyatsiz bo‘lsa, qolgan muammo quyida va ulanish xatosi endi tarix. Aynan shu ajratish aniq xabarni birinchi o‘qishning butun mazmunidir: bitta xato, bitta qatlam, bitta egasi. Shunday o‘qing va keyingi alomat taxmindan emas, ma’lum holatdan boshlanadi.