FreeBind va After=: systemd soketini VPN manziliga bog‘lash

Yuklanish paytida qat’iy VPN manzilini bog‘laydigan soket birligi tunnel uni tayinlashidan oldin muvaffaqiyatsiz bo‘lishi mumkin va uning orqasidagi xizmat hech qachon ishga tushmaydi. Ikki kalit tuzatishga o‘xshaydi va muammoning turli yarmini hal qiladi. FreeBind systemd ga manzil hali yo‘q bo‘lganda tinglovchini yaratishga imkon beradi. After= faqat vazifalarni tartibga soladi, shuning uchun narsalar qachon boshlanishini o‘zgartiradi, lekin manzilni ertaroq keltirmaydi.

Ikki xil muammo, ikki xil kalit

Birinchi muammo — bog‘lash muvaffaqiyatsizligi: yadro xost egalik qilmaydigan manzilda tinglashdan bosh tortadi, shuning uchun soket birligi darhol muvaffaqiyatsiz bo‘ladi va xizmat hech qachon faollashtirilmaydi. Ikkinchi muammo — tayyorlik muvaffaqiyatsizligi: manzil oxir-oqibat mavjud, lekin biror narsa tunnel trafik tashishidan oldin undan foydalanishga urinadi. FreeBind birinchisini hal qiladi va ikkinchisi uchun hech narsa qilmaydi. Tartib ko‘rsatmalari ikkalasini ham bevosita hal qilmaydi, chunki ular faqat nima qaysi tartibda boshlanishini belgilaydi. Sizda haqiqatan mavjud muvaffaqiyatsizlikni nomlash — butun qaror.

Qaysi biri sizda borligini xizmat tavsifidan emas, jurnaldan tasdiqlang. Bog‘lash muvaffaqiyatsizligi manzilni nomlaydi va uni tayinlash mumkin emasligini bildiradi. Tayyorlik muvaffaqiyatsizligi odatda keyinroq ko‘rinadi, vaqt tugashi yoki qarama-qarshi tomondan ko‘rilgan rad etilgan ulanish sifatida, jurnallarda esa butunlay sog‘lom soket birligi bo‘ladi.

FreeBind: tinglovchi manzildan oldin mavjud

FreeBind yadroga mahalliy bo‘lmagan manzilga bog‘lashga ruxsat berishni aytadi, shuning uchun systemd yuklanish paytida tinglovchi soketni yaratib, dastur ishga tushganda uni dasturga bera oladi. Soket faollashtirishning ma’nosi shu va soket o‘zining orqasidagi xizmatdan uzoqroq yashashi mumkinligining sababi ham shu.

[Socket]
ListenStream=
ListenStream=10.8.0.1:8443
FreeBind=yes

Bo‘sh tayinlash yangi yozuv qo‘shilishidan oldin sotuvchi birligidan meros qolgan tinglash yozuvlarini tozalaydi, bu esa har bir interfeysda javob beradigan qolgan wildcard tinglovchining oldini oladi. Manzil va portni o‘zingiznikiga almashtiring va faqat drop-in faylini emas, samarali birlikni tekshiring. Paket faylini joyida tahrirlash o‘rniga birlik nomi ostida drop-in ishlating, chunki keyingi paket yangilanishi tahrirni qayta yozadi va niyatdan hech qanday iz qoldirmaydi. So‘ng uni soket birligi kutgan qayta yuklash va qayta ishga tushirish tartibi orqali qo‘llang.

systemd soketi ma’lumotnomasi bu parametr ortidagi IPv4 va IPv6 xatti-harakatini hujjatlashtiradi, muhim tafsilot esa uning bog‘lashga tegishli ekani, yo‘naltirishga emas. Unda hech narsa manzil tayinlamaydi yoki VPN ishga tushirmaydi. FreeBind tinglovchiga berilgan ruxsat, interfeysning o‘rnini bosuvchi emas.

After= va Wants=: tartib tayyorlik emas

Tartib va talab alohida o‘qlar, ularni aralashtirish to‘g‘ri tartibda boshlanib, baribir muvaffaqiyatsiz bo‘ladigan birliklar yaratadi. After=vpn-client.service faqat ikkala ish ham boshlansa, bu ikkinchisining boshlanishini kutishini bildiradi. U VPN ni tortmaydi va VPN ulanishni tugatishini kutmaydi.

Wants= va Requires= kabi talab ko‘rsatmalari faollashtirish bilan shug‘ullanadi va bog‘liqlik muvaffaqiyatsiz bo‘lganda nima bo‘lishi bilan farq qiladi: biri davom etadi, ikkinchisi to‘xtaydi. Hech biri ulangan tunnel nimani anglatishini bilmaydi. VPN jarayoni manzil tayinlanmasdan ham faol bo‘lishi mumkin, yoki manzil tayinlanib, sherigiga yo‘l bo‘lmasligi mumkin, ikkala holat ham bog‘liqlikni qanoatlantiradi. Agar dasturga manzil mavjudligi kerak bo‘lsa, jarayonning boshlanishini tayyorlik dalili deb hisoblash o‘rniga o‘sha shartni aniq modellashtiring.

systemctl cat va systemctl show -p After -p Wants -p Requires bilan birlik aslida nimani e’lon qilishini tekshiring. Uch xil katalogdagi drop-in lar siz hech qachon yozmagan ko‘rsatmalarni qo‘shishi mumkin, systemd esa faqat samarali birlikni o‘qiydi.

network-online.target nima qilmaydi

network-online.target dan keyin tartiblangan birlik tarmoq menejeri tarmoqni foydalanishga yaroqli deb e’lon qilishini kutadi, bu yuklanishdagi sinxronizatsiya nuqtasi, doimiy shart emas. Muayyan tunnel ko‘tarilganmi-yo‘qmi, bu haqda hech narsa demaydi va VPN tushdan keyin qayta ulanganda u yana ishga tushmaydi. Uni qayta ulanish monitori deb qarash — bu maqsadning eng keng tarqalgan noto‘g‘ri o‘qilishi.

systemd loyihasi bu farqni bevosita hujjatlashtiradi, amaliy natija esa tunnel manziliga muhtoj bo‘lgan har bir narsa bog‘liqlikka o‘zi ega bo‘lishi kerak. network-online ni kutib, keyin tunnel manzilini bog‘laydigan birlik faqat tunnel tasodifan birinchi ko‘tarilganda to‘g‘ri bo‘ladi, bu esa tasodif, loyiha emas.

Siz haqiqatan tanlagan hayot tsiklini sinang

Toza yuklanishni, manzil paydo bo‘lgandan keyingi so‘rovni va VPN yiqilib qaytgandan keyingi xatti-harakatni sinang. Bu uch holat ishlaydigan tinglovchini ishlaydigan xizmatdan ajratadi.

systemd-analyze verify myapp.socket
systemctl cat myapp.socket
ss -ltn "sport = :8443"

Birinchi buyruq qayta ishga tushirishdan oldin birlik fayli xatolarini ushlaydi, ikkinchisi birlashtirilgan birlikni ko‘rsatadi, uchinchisi tinglovchi bor-yo‘qligini va qaysi manzilda ekanini isbotlaydi. Tunnel manzilini kutgan joyda wildcard manzilidagi tinglovchi — bo‘sh ListenStream olib tashlashi kerak bo‘lgan o‘sha qoldiq. Manzil siljigan-siljimaganini ko‘rish uchun VPN qayta ulangandan keyin uchinchi buyruqni takrorlang.

Hayot tsiklini ataylab tanlang: barqaror manzil qaytishini kutadigan erkin bog‘langan tinglovchi yoki tunnel bilan to‘xtab, tiklanishda qayta boshlanadigan xizmat. Bular turli loyihalar va turli yo‘llar bilan muvaffaqiyatsiz bo‘ladi. So‘ng kirish siyosatini siz nazarda tutgan manbalar va yo‘llarga bog‘langan holda saqlang, chunki maqsad manzilini bog‘lash qabul qilingan paketlar ishonchli interfeysdan kelgan bo‘lishini talab qilmaydi.