Nima uchun VPN birligi tarmoqdan oldin ishga tushib, keyin o'ladi

Mashinani yuklang, tizimga kiring va tunnel ko'tarilib, bir necha soniyadan keyin o'lganini bilib oling. Profil joyida edi, sertifikat joyida edi, va qolgan yagona iz — o'sha yuklanish jurnali. Odatda sodir bo'lgan narsa poyga: birlik mashinada manzil bo'lishidan oldin ishga tushgan, va u e'lon qilgan tartib ko'rinadigan ma'noni bermagan. Quyidagilarning barchasi shu poygani dalillardan isbotlash va uni to'g'ri yopish haqida.

Maqsad uchrashuv joyi, boshqaruvchi emas

network-online.target tarmoq nima ekanini bilmaydi. Bu ulanish ishlatishga yaroqli bo'lgunga qadar ishga tushishni kechiktirishi kerak bo'lgan xizmatni to'playdigan muvofiqlashtirish nuqtasi bo'lib, ta'rifni mashinaga egalik qiluvchi tarmoq menejeriga topshiradi. Ko'pchilik ish stollari va serverlarda bu NetworkManager yoki systemd-networkd taqdim etadigan kutish xizmatini anglatadi. Ikkalasini ham yoqmasangiz, maqsadning kutadigan hech narsasi qolmaydi, shuning uchun u biror narsa uni tortib olgan lahzada tugaydi, va bu DHCP javob berishidan ancha oldin bo'lishi mumkin. Birligingizdagi tartib satri halol edi va shunga qaramay foydasiz.

Shuning uchun birinchi savol — birligingiz nima e'lon qilishi emas. Bu mashinada biror narsa haqiqatan kutishni bajarayotganmi, degan savol.

Birlik fayli o'rniga oxirgi yuklanishni o'qing

Birlik fayllari niyatni tasvirlaydi, jurnal esa nima bo'lganini tasvirlaydi. Faqat o'sha yuklanishni so'rang, monoton vaqt belgilari bilan, har bir xabar bitta soatda o'tirishi uchun. So'ng ikki satrni toping: tunnel birligi ishga tusha boshlagan lahza, va manzil paydo bo'lgan yoki kutish xizmati tugagan lahza. Bu ikki sonni tartibga soling va poyga yo tasdiqlanadi, yo istisno qilinadi.

Bog'liqlik ko'rinishi buni tasdiqlaydi. Agar tunnel birligi uchun muhim zanjirda kutish xizmati bo'lmasa, bu yo'lda hech narsa ishga tushishni kechiktirmagan, va maqsad siz taxmin qilgan ishni bajarmagan. Ikki ko'rinish, bir xulosa.

systemctl list-units --type=service --state=running | grep wait-online
journalctl -b -o short-monotonic -u openvpn-client@office

Kutishni qo'shing, so'ng qayta urinishni

Paketlangan birlikni tahrirlash o'rniga drop-in ishlating, paket yangilanishi o'zgarishni jimgina tashlab yubormasligi uchun. Ikki direktiva muhim: birlik maqsaddan keyin tartiblanishi kerak va maqsadni o'sha tranzaksiyaga tortishi kerak. Faqat tartib maqsadni chaqirmaydi; buni istak qiladi.

OpenVPN mijozi paketlangan birligi allaqachon ikkalasini ham olib yuradi. Qo'lda yozilgan birliklar odatda bittasini yoki hech birini olib yuradi, buni biror narsa qo'shishdan oldin tekshirishga arziydi.

[Service]
Restart=on-failure
RestartSec=15

Nima uchun qat'iy uyqu tuzoq

ExecStartPre ichidagi uyqu tartibni tuzatish kabi tuyuladi va qo'shimcha qadamlar bilan kechikish kabi harakat qiladi. U har bir yuklanishni sekinlashtiradi, sog'lom bo'lganlarini ham, va ulanish siz tanlagan sondan ko'proq vaqt olsa ham yutqazadi.

Eng yomoni, u kutish xizmati ishlayotganini yashiradi, shuning uchun keyingi nosozlik xuddi shu muammoning boshqa vaqti sifatida emas, butunlay yangi muammo sifatida ko'rinadi. Qisqa qayta ishga tushirish kechikishi yaxshiroq asbob: sog'lom yuklanishda hech narsa turmaydi va yutqazilgan poygani yana bir urinishga aylantiradi. Intervalni kamtar tuting va birlik muvaffaqiyat qozonishiga yo'l qo'ying. Agar u abadiy qayta ishga tushsa, profil buzilgan va qancha qayta urinish ham buni o'zgartirmaydi, shuning uchun intervalni oshirish o'rniga jurnalni o'qing.

Tartib to'g'ri bo'lib, nomlar hali ham ishlamasa

Tunnel marshruti bo'lgan faol birlik tartib o'z ishini qilganini va qolgan nuqson bir qatlam yuqorida ekanini bildiradi. Odatiy shakl — tunnelning up skripti qo'llaydigan rezolver sozlamasi, ulanish yoki rezolver uni ushlab turishga tayyor bo'lishidan oldin. Nosozlik paytidagi rezolver holatini tunnel birligi qayta ishga tushirilgandan keyingi holat bilan solishtiring.

Agar qayta ishga tushirish qidiruvlarni tuzatsa, sizda noto'g'ri DNS server emas, ishga tushish tartibi nuqsoni bor, va bu ikkisiga alohida tuzatishlar kerak. So'ng hamma narsani xizmatni qayta ishga tushirish o'rniga sovuq yuklash bilan isbotlang, chunki qayta ishga tushirish allaqachon ko'tarilgan tarmoqqa qarshi ishlaydi va siz quvayotgan nuqsonni aynan yashiradi. Buni ulanishni ataylab sekin qilib takrorlang, va faqat tarmoq tez bo'lganda ishlaydigan birlikni hali ham buzilgan deb hisoblang.