FreeBind və After=: systemd soketini VPN ünvanına bağlamaq

Açılışda sabit VPN ünvanına bağlanan soket vahidi tunel həmin ünvanı təyin etməzdən əvvəl uğursuz ola bilər və arxasındakı xidmət heç vaxt başlamaz. İki açar düzəliş kimi görünür və problemin fərqli yarılarını həll edir. FreeBind systemd-ə dinləyicini ünvan hələ yoxkən yaratmağa imkan verir. After= isə yalnız işləri sıralayır, yəni nələrin nə vaxt başladığını dəyişir, amma ünvanı bir az da tez gətirmir.

İki fərqli problem, iki fərqli açar

Birinci problem bağlama uğursuzluğudur: nüvə hostun sahib olmadığı ünvanda dinləməyə icazə vermir, buna görə soket vahidi dərhal uğursuz olur və xidmət heç vaxt aktivləşmir. İkinci problem hazırlıq uğursuzluğudur: ünvan sonda mövcuddur, lakin nəsə ondan tunel trafik daşımadan əvvəl istifadə etməyə çalışır. FreeBind birincini həll edir, ikinci üçün heç nə etmir. Sıralama direktivləri heç birini birbaşa həll etmir, çünki onlar yalnız nələrin hansı ardıcıllıqla başladığını müəyyən edir. Həqiqətən yaşadığınız uğursuzluğu adlandırmaq bütün qərarı təşkil edir.

Hansının sizdə olduğunu xidmət təsvirindən deyil, jurnaldan təsdiqləyin. Bağlama uğursuzluğu bir ünvan adlandırır və onun təyin edilə bilmədiyini bildirir. Hazırlıq uğursuzluğu adətən sonra görünür: uzaq tərəfdən görünən fasilə və ya rədd edilmiş bağlantı kimi, jurnallarda isə tamamilə sağlam soket vahidi olur.

FreeBind: dinləyici ünvandan əvvəl mövcuddur

FreeBind nüvəyə qeyri-lokal ünvana bağlanmaya icazə verməsini deyir, beləliklə systemd dinləyən soketi açılışda yarada və tətbiq nə vaxt başlasa ona verə bilər. Soket aktivləşdirməsinin mənası budur və soketin arxasındakı xidmətdən uzun yaşamasının səbəbi də budur.

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

Boş təyinat yeni giriş əlavə olunmazdan əvvəl satıcı vahidindən miras qalan dinləmə girişlərini təmizləyir və bununla hər interfeysdə cavab verən qalıq wildcard dinləyicisinin qarşısını alır. Ünvanı və portu özünüzlə əvəz edin və yalnız drop-in faylını deyil, effektiv vahidi yoxlayın. Paket faylını yerində redaktə etmək əvəzinə vahid adı altında drop-in istifadə edin, çünki növbəti paket yeniləməsi redaktəni üzərinə yazacaq və niyyətdən heç bir iz qoymayacaq. Sonra onu soket vahidinin gözlədiyi yenidən yükləmə və yenidən başlatma proseduru ilə tətbiq edin.

systemd soket sənədi bu seçimin arxasındakı IPv4 və IPv6 davranışını sənədləşdirir və vacib detal onun marşrutlaşdırmaya deyil, bağlanmaya aid olmasıdır. Orada heç nə ünvan təyin etmir və ya VPN başlatmır. FreeBind dinləyiciyə verilən icazədir, interfeysin əvəzi deyil.

After= və Wants=: sıralama hazırlıq deyil

Sıralama və tələb ayrı oxlardır və onları qarışdırmaq düzgün ardıcıllıqla başlayan, sonra yenə uğursuz olan vahidlər yaradır. After=vpn-client.service yalnız o deməkdir ki, hər iki iş başlasa, bu iş digərinin başlamasını gözləyir. O, VPN-i çəkmir və VPN-in qoşulmasını bitirməsini gözləmir.

Wants= və Requires= kimi tələb direktivləri aktivləşdirmə ilə məşğul olur və asılılıq uğursuz olduqda nə baş verdiyinə görə fərqlənirlər: biri davam edir, digəri dayanır. Heç biri qoşulmuş tunelin nə demək olduğunu bilmir. VPN prosesi ünvan təyin edilmədən aktiv ola bilər, ya da ünvan təyin edilib qarşı tərəfə marşrut olmadan, və hər iki vəziyyət asılılığı qane edir. Tətbiq ünvanın mövcud olmasını tələb edirsə, prosesin başlamasını hazırlıq sübutu saymaq əvəzinə həmin şərti açıq şəkildə modelləşdirin.

Vahidin həqiqətən nə bəyan etdiyini systemctl cat və systemctl show -p After -p Wants -p Requires ilə yoxlayın. Üç fərqli qovluqdan gələn drop-in-lər heç vaxt yazmadığınız direktivlər əlavə edə bilər və systemd yalnız effektiv vahidi oxuyur.

network-online.target nə etmir

network-online.target-dən sonra sıralanan vahid şəbəkə menecerinin şəbəkəni istifadəyə yararlı elan etməsini gözləyir; bu, davamlı şərt deyil, açılış sinxronizasiya nöqtəsidir. Müəyyən bir tunelin qalxıb-qalxmadığı barədə heç nə demir və VPN günorta yenidən qoşulanda bir daha işə düşməyəcək. Onu yenidən qoşulma monitoru kimi qəbul etmək həmin hədəfin ən çox yayılmış səhv oxunuşudur.

systemd layihəsi bu fərqi birbaşa sənədləşdirir və praktik nəticə budur ki, tunel ünvanına ehtiyacı olan hər şey asılılığa özü sahib olmalıdır. network-online-ı gözləyib sonra tunel ünvanına bağlanan vahid yalnız tunel təsadüfən birinci qalxdıqda düzgündür, bu isə dizayn deyil, təsadüfdür.

Həqiqətən seçdiyiniz həyat dövrünü sınaqdan keçirin

Təmiz açılışı, ünvan göründükdən sonra gələn sorğunu və VPN düşüb qayıtdıqdan sonrakı davranışı sınayın. Bu üç hal işləyən dinləyicini işləyən xidmətdən ayırır.

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

Birinci əmr yenidən başlatmadan əvvəl vahid faylı səhvlərini tutur, ikincisi birləşdirilmiş vahidi göstərir, üçüncüsü isə dinləyicinin mövcud olub-olmadığını və hansı ünvanda olduğunu sübut edir. Tunel ünvanı gözlədiyiniz yerdə wildcard ünvanındakı dinləyici məhz boş ListenStream-in aradan qaldırmalı olduğu qalıqdır. Ünvanın yerini dəyişib-dəyişmədiyini görmək üçün VPN yenidən qoşulduqdan sonra üçüncü əmri təkrarlayın.

Həyat dövrünü qəsdən seçin: ya sabit ünvanın qayıtmasını gözləyən sərbəst bağlanmış dinləyici, ya da tunellə birlikdə dayanan və bərpa zamanı yenidən başlayan xidmət. Bunlar fərqli dizaynlardır və fərqli şəkildə uğursuz olurlar. Sonra giriş siyasətini nəzərdə tutduğunuz mənbələrə və yollara bağlı saxlayın, çünki təyinat ünvanına bağlanma qəbul edilmiş paketlərin etibarlı interfeysdən gəlməsini tələb etmir.