OpenVPN hook skripti hozir qurgan tunnelni ishlata oladimi?

Hook skripti tunnelning narigi tomoniga yeta oladimi, bu uch shartga bog'liq: u qaysi hodisaga bog'langan, skript ishlayotganda OpenVPN hali o'z ishga tushish ketma-ketligi ichidami, va ish shu ketma-ketlikdan ajratilganmi. Ko'p skriptlar uchinchisida muvaffaqiyatsiz bo'ladi. Uyqu qo'shish hayot sikli muammosini vaqt muammosi deb qaraydi va faqat chalg'itishga yetadigan darajada ishlaydi.

Avval hodisani, keyin ishni kechiktirish mexanizmini, keyin kechiktirilgan ish bajariladigan joyni hal qiling. Bu uch qaror mustaqil, va ularni aralashtirish ikki qatorli hookning butun tushlikdan keyingi vaqtga aylanishining sababi.

Nega hook o'zini kutayotgan tunnelni kutadi

OpenVPN hooklarini paketlarni harakatga keltiradigan o'sha jarayon ichida sinxron chaqiradi. up tun yoki tap qurilmasi mavjud bo'lganda, lekin birorta marshrut qo'shilishidan oldin ishga tushadi, route-up esa marshrutlardan keyin ishga tushadi; bu ikki lahzaning hech biri qarshi tomon javob berishiga va'da bermaydi. Har qanday hookning skripti ishlab turganda demon uzatmaydi, shuning uchun tunnel orqali trafik o'tishini kutayotgan buyruq o'zini kutayotgan tunnelni kutadi. Aynan shu doiraviy kutish qo'lda ishga tushirish o'tishining va hookning vaqti tugashining sababi.

Ko'rinib turgan yamoq, ya'ni bir necha soniya uxlash, ba'zan ishlaydi, chunki uzoq tomon o'zi ko'tarildi, uyqu biror narsani tuzatgani uchun emas. Tayyorlikni so'raydigan yordamchi boshqa javob: hook qaytadi, uzatish boshlanadi va yordamchi kerakli narsani u haqiqatan mavjud bo'lganda oladi.

Hookni qulaylikka emas, hodisaga qarab tanlang

up ni faqat qurilma kerak bo'lgan ishga, route-up ni marshrutlar kerak bo'lgan ishga bog'lang, client-connect va client-disconnect ni esa server tomonida har bir mijoz uchun vazifalarga qoldiring. Uzilishda tozalash ikki marta bajarilishiga chidashi kerak, chunki doimiy interfeys orqali qayta ulanish to'liq qayta ishga tushish bilan bir xil ketma-ketlikka rioya qilmaydi. Serverda client-connect demon ishga tushganda emas, mijoz autentifikatsiya qilganda ishga tushadi, buni mantiqni u yerga ko'chirishdan oldin tasdiqlashga arziydi. Agar ish bitta ulanishga emas, xizmatning hayot siklida bo'lsa, systemd birligi har qanday hookdan yaxshiroq uy.

Hook buyruqlarini demon to'g'ridan-to'g'ri, orada qobiqsiz bajaradi, shuning uchun up satridagi ifconfig_remote so'zma-so'z matn sifatida keladi. Buyruqni aniq qobiqqa o'rang yoki mantiqni muhitni o'qiydigan skriptda saqlang. ipchange o'z argumentlarini qo'shadigan bitta direktiva: u buyruqqa manzil va portni beradi, shuning uchun hech kim uchun yozilmagan skript ikkita kutilmagan argumentni ko'radi.

Ishni ajratishning uch yo'li

Birinchi variant yordamchini hookning ichidan fonga yuborish: uni setsid yoki systemd-run --scope bilan ishga tushiring, meros qolgan deskriptorlarni yoping va darhol nol bilan chiqing. Ikkinchisi hook kichik holat faylini yozishi va systemd taymeri yoki yo'l birligi unga amal qilishi, bu hookni sodda saqlaydi va qayta urinish siyosatini jurnallar bor joyga qo'yadi. Uchinchisi hookdan butunlay voz kechib, ishni VPN xizmatidan keyin tartiblangan birlikka ko'chirish, bu ish umuman har bir ulanishga tegishli bo'lmasa to'g'ri javob. Uchovi ham bitta qoidani bo'lishadi: hook tunnel kerak bo'lishidan oldin qaytishi kerak.

Nimani tanlasangiz ham, yordamchini idempotent va kuzatiladigan qiling. Ikki ustma-ust tushgan chaqiruv bir xil qaytarilmas amalni ikki marta bajarmasligi kerak, va muvaffaqiyatsiz yordamchi inson o'qiy oladigan narsa qoldirishi kerak.

Sandbox nosozliklarini hayot sikli nosozliklaridan ajrating

Skript root so'rovidan ishlab, xizmat sifatida muvaffaqiyatsiz bo'lsa, sabab odatda tarmoq emas, sandbox. Cheklovchi ProtectHome, faqat o'qish uchun ProtectSystem yoki mavjud bo'lmagan ish katalogi skriptni yoki uning ma'lumotlarini yetib bo'lmaydigan qilib qo'yishi mumkin, va SELinux xostida faylga bajarishga ruxsat beradigan kontekst ham kerak. Birlikni systemctl cat openvpn-server@server bilan, jurnalni journalctl -u openvpn-server@server -n 80 bilan o'qing, keyin ulanish vaqti tugashini emas, ruxsat yoki kontekst xatosini qidiring. Sandboxni o'chirish birinchi emas, oxirgi qadam bo'lishi kerak.

Hayot sikli nosozligi boshqacha ko'rinadi: hook boshlanadi, yordamchi ishlaydi, va soket hali u yerda emas. Hookning o'zidan vaqt tamg'asi bo'lgan satr yozing, uzib qayta ulang, va hodisalarni tartib bilan o'qing. Yordamchiga tunnel haqiqatan kerak bo'lsa, belgilangan vaqt uxlash o'rniga tayyorlikni so'rashiga ruxsat bering.

Uch maydon keyingi hisobotni foydali qiladi: qaysi hook ishladi, qaysi hisobdan foydalandi va qayerda to'xtadi. Ularsiz har bir keyingi tekshiruv boshidan boshlanadi.