OpenVPN active (exited) deyaptimi? Siz ishga tushirgan instansni toping

Siz tunnelni tekshirasiz, systemctl status openvpn ishlatasiz va Main PID bo'lmagan hamda bo'sh jarayonlar ro'yxati bilan active (exited) olasiz. Tabiiy o'qish — xizmat ishga tushib o'ldi, shuning uchun unitni ochib, /bin/true topib, paket buzilgan degan xulosaga kelasiz. Debian paketida bu holat loyihalanganidek ishlayotgan wrapper, tunnel esa u ishga tushiradigan instance-unitlardan birida yashaydi. Umumiy unit qaysi instans uni qurganini hech qachon aytmaydi.

Bu unitda active (exited) aslida nimani anglatadi

Paketlangan unit bir martalik vazifa: uning ExecStart /bin/true, va tugagan unitning active (exited) deb xabar qilinib turishini RemainAfterExit=yes ta'minlaydi. Shu direktivani olib tashlasangiz, o'sha muvaffaqiyatli /bin/true vazifasi inactive (dead) bilan tugaydi, bu odamlar kutadigan va qarama-qarshi tomonga noto'g'ri o'qiydigan aynan o'sha holat. Buyruq shunchaki o'rinbosar, unit esa boshqa unitlar bajaradigan ish haqida hisobot beradi. Bu tartibda hech narsa buzilmagan, /bin/true ni almashtirish tunnelni emas, paketlash shartnomasini o'zgartiradi.

Wrapper vakolat beradi. Paket konfiguratsiyasi yoki uning systemd generatori taqdim etadigan instance-unitlarni ishga tushiradi, shuning uchun bo'sh jarayonlar ro'yxati tunnel haqida hech narsani isbotlamaydi. Hech qanday instans tanlanmasa ham wrapper baribir muvaffaqiyat qozonadi va baribir hech narsani ishga tushirmaydi. Holat wrapper ishlaganmi-yo'qmi degan savolga javob beradi, tunnel bormi-yo'qmi deganiga emas.

Qavs ichidagi so'zni emas, status chiqishining uch satrini o'qing. Loaded systemd o'qigan unit faylini nomlaydi, Active oxirgi muvaffaqiyatli ishga tushishning vaqt belgisini olib yuradi, Main PID yo'qligi esa tugagan bir martalik vazifaga mos keladi. O'sha uch satr bu wrapperni ishga tushgandan bir soniya o'tib qulagan xizmatdan ajratishning ham yo'lidir.

Statusni qayta o'qishdan oldin unitlarni ro'yxatga oling

Nima ishlayotganini so'rashdan oldin systemd dan nima borligini so'rang. Hech qanday instans yaratilmasa ham shablon o'rnatilgan bo'lishi mumkin, tunnelni esa faqat yaratilgan unit olib yuradi. Yuklangan to'plamdan boshlang:

systemctl list-units 'openvpn*'

Bu ro'yxat systemd ayni damda yuklagan narsa va tunnel inventariga eng yaqin narsa. O'rnatilgan unit fayllari boshqa savolga javob beradi, hech narsa yaratilmaganda ham bu ro'yxat shablonni ko'rsatadi:

systemctl list-unit-files 'openvpn*'

Ikkala ro'yxatni birga o'qing, chunki ikkinchisidagi shablon va birinchisidagi instans ikki xil javob. Mavjud shablon va ishlayotgan instans bir xil fakt emas, va faqat ikkinchisi tunnel demakdir. Paket tuzilmalari distributivlar va OpenVPN versiyalari orasida ham farq qiladi. Eski openvpn@ shabloni, ajratilgan client va server juftligi va distributiv wrapper o'z paketida qonuniy bo'lishi mumkin.

Topgan qo'llanmangizga emas, o'z mashinangizga moslashing. Boshqaning chiqishidagi instans nomi office bo'lishi mumkin, sizniki esa home yoki work. O'tadigan narsa — usul, satr emas.

Instans nomidan u o'qiydigan faylgacha boring

Upstream client shablonida unitning ish katalogi /etc/openvpn/client va uning buyrug'i o'sha yerdan %i.conf oladi, shuning uchun openvpn-client@office /etc/openvpn/client/office.conf ni o'qiydi. Misolga ishonish o'rniga o'rnatilgan unitda bu moslikni tasdiqlang, chunki sizdagi shablon eskiroq yoki distributiv qayta yozilgan bo'lishi mumkin:

systemctl cat [email protected]

O'sha chiqishning pastida ko'rinadigan drop-inlarni o'qing, chunki .d/ ostidagi fayl ExecStart, ish katalogi yoki konfiguratsiya yo'lini o'zgartirishi mumkin. Siz office.ovpn deb yuklagan profil instans ochadigan fayl emas. Shu tafovut odatda xatoning siz hech qachon tahrirlamagan yo'lni nomlashiga sabab bo'ladi.

Profil ichidagi nisbiy yo'llar keyingi tuzoq. Asosiy faylni ko'chirib, ca, cert va key havolalarini nisbiy qoldirish yo'qolgan-fayl xatosini boshqa yo'qolgan-fayl xatosi bilan almashtiradi. Ikkinchisi mavjudligiga ishonchingiz komil bo'lgan faylga ishora qiladi, shuning uchun profil katalogi fayl nomidan muhimroq.

Uni ishga tushiring, so'ng o'sha instansning jurnalini o'qing

Hozir tekshirgan instansni ishga tushiring, chunki umumiy unit jurnalida tunnel xatolari bo'lmaydi. So'ng bu yuklanishning jurnalini o'qib, shu tartibda konfiguratsiya xatosi, faylga kirish xatosi va ulanish xatosini qidiring, chunki har biri ishga tushishning boshqa bosqichida muvaffaqiyatsiz bo'ladi.

sudo systemctl start [email protected]
journalctl -u [email protected] -b

Ishga tushirish va yoqish alohida qarorlar: start unitni hozir bajaradi, enable keyingi yuklanishni tayyorlaydi, enable --now esa ikkalasini bir qadamda qiladi. daemon-reload unit ta'riflarini qayta o'qiydi va ishlayotgan jarayonni qayta ishga tushirmaydi hamda tahrirlangan profilni qo'llamaydi. Profilni o'zgartirgandan so'ng instansni qayta ishga tushiring, chunki faylni qayta o'qiydigan narsa shu.

Bir xil tunnelga ikkinchi menejer qo'ymang

NetworkManager va OpenVPN 3 sessiya menejerlari o'z ulanish holatiga ega, va ulardan birining yonidagi systemd instansi bir tunneldagi ikki egaga olib keladi. Alomat — ko'tarilib, bir necha soniyadan keyin almashtiriladigan tunnel yoki to'xtab turishdan bosh tortadigan tunnel. Distributivingiz ish stoli uchun hujjatlashtirgan menejerni tanlang va serverda systemd ni ataylab ishlating.

Instans ishga tushirishdan oldin mavjud ega bor-yo'qligini tekshiring. Ish stoli appleti ulanishni ko'rsatganda, siz ishga tushirgan instans uni to'ldirish o'rniga u bilan raqobatlashadi. Ikkalasini ishga tushirib, tartib saqlanadi deb umid qilish o'rniga ishlatmayotgan menejerni o'chiring. Bu ziddiyat, shuningdek, tunnel o'rnatilib, keyin siz hech qachon ishga tushirmagan jarayon tomonidan buzilgan jurnallarni ham tushuntiradi.

Asl savolga instans nomi, u o'qigan fayl va muvaffaqiyatsiz jurnal satri bilan javob bering. OpenVPN ning systemd integratsiyasi haqidagi eslatmalari shablon tuzilishini va instans nomi hal qilinadigan fayl mosligini tavsiflaydi.