systemd VPN xizmatini to'xtatadi: Type= ni mijozga moslang

Birliklar to'g'ri ko'rinishi mumkin, systemctl start muvaffaqiyat haqida xabar berishi mumkin, va o'n soniyadan keyin xizmat nofaol holda qoladi. Yoki ishga tushirish chegarasi to'xtatmaguncha har yarim daqiqada qayta ishga tushadi. Ikkala xatti-harakat ham tarmoq nosozligi emas: birlik mijozning haqiqatda qiladigan ishiga mos kelmaydigan jarayon umrini tasvirlaydi. Mijoz fork qilib chiqishi yoki sessiyani sozlab darhol chiqishi mumkin.

Nima uchun birlik muvaffaqiyatli ishga tushgandan bir necha soniya o'tib nofaol bo'lib qoladi

systemd holatni o'zi ishga tushirgan jarayondan chiqaradi, shuning uchun Type= o'sha jarayon haqidagi da'vo, hujjat emas. Type=simple bilan birlik buyruq ishlab turganda faol hisoblanadi va u qaytganda nofaol bo'ladi. Shuning uchun ulanishni yordamchiga topshirib chiqib ketadigan mijoz tunnel ishlab turgan bo'lsa ham halokat kabi ko'rinadi. Keyin jurnal ishga tushish va to'xtash naqshini ko'rsatadi, u buzilgan ikkilik fayl kabi o'qiladi.

Tarmoq sozlamalariga tegishdan oldin birlik turini mijozning xatti-harakati bilan birga o'qing.

Mijozga mos keladigan turni tanlang

Ikki naqsh ko'pchilik sotuvchi CLI'larini qamrab oladi: sessiyani sozlab chiqadigan buyruq va qaytishdan oldin yordamchini fork qiladigan buyruq. Har biriga boshqa birlik shakli kerak.

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/bin/protonvpn-cli connect -f
ExecStop=/usr/bin/protonvpn-cli disconnect

oneshot RemainAfterExit=true bilan birga buyruq qaytgandan keyin ham birlikni faol ushlab turadi, bu sozla va chiq naqshiga mos keladi, to'xtatish buyrug'i esa xizmatga toza yopilish beradi. Fork qiladigan mijoz bir xil shaklni saqlaydi, lekin systemd bolani kuzatishi uchun Type=forking kerak. Restart=on-failure, RestartSec=30 va cheklangan StartLimitBurst ni o'rnating, ta'minotchi uzilishi xatoni ko'madigan qayta ishga tushish halqasiga aylanmasligi uchun.

Nazorat ostidagi mijozning demon bo'lishiga hech qachon yo'l qo'ymang

systemd dan tashqaridagi nazoratchilar ham xuddi shu devorga uriladi. Demon bo'lgan mijozni ishga tushiradigan runit skripti darhol nazoratchiga qaytadi, u esa bu qaytishni halokat deb o'qib yana bir nusxa ishga tushiradi. Har bir nazoratchi oldingi plandagi jarayonga egalik qilishni kutadi, xuddi sshd -D oldinda qolgani kabi. Nazorat ostidagi buyruqlar uchun demon bayrog'ini olib tashlang va fon ishini nazoratchiga qoldiring. Tunnel paydo bo'lishidan oldin qaytadigan o'ram skriptlar ham xuddi shunday chalkashlik keltiradi.

O'zidan ajralib chiqadigan jarayon uni kuzatishi kerak bo'lgan hamma narsaga ko'rinmas.

Sessiya tugaydi va tunnelni o'zi bilan olib ketadi

Ish stoli sessiyasi o'zi ishga tushirgan mijozga egalik qiladi. Kirishni tugating, sessiya shinasi yo'qoladi va tunnelni ham olib ketadi, shuning uchun oxirgi oyna yopilganda grafik mijozning ulanishi tez-tez uziladi. Serverlar o'z-o'zidan ko'tariladigan tizim birligi yoki NetworkManager profilidan foydalanishi kerak. Foydalanuvchi birligi faqat tunnel kirish bilan tugashi kerak bo'lganda mantiqiy, shuning uchun uni grafik sessiya nishoniga bog'lang va buni tavsifida yozing.

Xizmat foydalanuvchisi xuddi shu muammoning ikkinchi yarmi. root ga tegishli va rejimi 0600 bo'lgan kalitni boshqa hisob ostida ishlaydigan birlik o'qiy olmaydi, sizning qobig'ingizda sudo nima erishgan bo'lsa ham.

systemctl cat openvpn-server@work
sudo chown -R openvpn:network /etc/openvpn/server
sudo find /etc/openvpn -type f -perm /077 -ls

Manzil paydo bo'lgandan keyin bog'liq birliklarni tartiblang

Demon hali yaratilmagan tunnel manziliga bog'langanda, u Cannot assign requested address bilan chiqadi. Tuzatish qayta urinish halqasi emas, aniq tartiblashdir.

[Unit]
After=network.target [email protected]
Requires=sys-devices-virtual-net-wg0.device

After= ishlarni tartiblaydi, qurilma birligidagi Requires= esa bog'liqni interfeys mavjudligiga bog'laydi, bu faqat tarmoq nishonini kutishdan kuchliroq. Tahrirdan keyin menejerni qayta yuklang va bog'liq xizmatni qayta ishga tushiring, so'ng tartib ishladi deb o'ylash o'rniga uning jurnalini o'qing. Mijoz chiqishini jurnalga StandardOutput=journal yoki log varianti bilan yuboring, chunki hech kim ochmaydigan faylga yozadigan nazorat ostidagi mijoz hech qachon ishga tushmagan bilan bir xil ko'rinadi.

So'ng bir marta qayta yuklang va tunnel qurilmasi paydo bo'lgandan keyin birlik faol ekanini tasdiqlang. Faqat systemctl start bilan tekshirilgan tuzatish tuzatishi kerak bo'lgan yuklanish tartibini sinamagan.