Systemd və NetworkManager: yüklənmədə VPN-i kim başladır?

Eyni imicdən iki Ubuntu maşını, bir VPN profili, girişdə əks nəticələr: birində tunel iş masası görünməzdən əvvəl qalxır, digərində isə heç vaxt qalxmır. Burada dəyişən profil deyil. Fərq ondadır ki, üç komponentdən hansına onu başlatmaq tapşırılıb və bu üçü bir açarı paylaşmır.

Onları yan-yana müqayisə etmək təxmin etməkdən sürətlidir. Hər biri tanınan şəkildə uğursuz olur və müqayisəni dəyərli edən də elə budur.

Fərqli tetikleyiciləri olan üç başladıcı

Paketlə gələn openvpn xidməti ən köhnə yoldur. Onun init skripti /etc/default/openvpn faylından avtomatik başlatma siyahısını oxuyur. Əgər o siyahı şərh edilibsə və ya boş buraxılıbsa, skript həmin qovluqda tapdığı hər konfiqurasiyanı başladır, sizin əlavə etdiyiniz tək konfiqurasiyanı deyil. Bir tunel üçün əlavə edilmiş bir fayl səssizcə bir neçəsini işə sala bilər.

İnsanların səhv konfiqurasiya etdiyi ikinci sıradır. NetworkManager idxal edilmiş profili saxlayır və onu başladacaq, lakin yalnız başqa bir bağlantının ikincisi kimi, yəni tetikleyici VPN-ə deyil, şəbəkə bağlantısına aiddir.

Quraşdırma xərcini və əhatə dairəsini müqayisə edin

Init skripti yolu bir sətirə başa gəlir və maşındakı hər konfiqurasiyanı əhatə edir. Bu, marşrutlaşdırıcı üçün yaxşıdır və müxtəlif şəbəkələrə qoşulan noutbuk üçün səhvdir. NetworkManager yolu UUID axtarışına başa gəlir və tuneli bir əsas bağlantıya bağlayır. İş SSID-də qalxır, otel şəbəkəsində isə aşağı qalır.

Əl ilə yazılmış unit ən çox xərc tələb edir və ən çox nəzarət verir, o cümlədən digər xidmətlərə nisbətən sıralama. Həlledici amil əhatə dairəsidir. Maşının bir şəbəkəsi və bir tuneli varsa, paketlənmiş xidmət dürüstdür və proqnozlaşdırıla biləndir. Tunel müəyyən bir Wi-Fi şəbəkəsini izləməlidirsə, ikincil üçündən yalnız biridir ki, bu şərti əlavə skript olmadan ifadə edir.

Bir sahib seçin və digərlərini silin

İki sahib tərəfindən başladılan profil yüklənmələr arasında dəyişən vaxt yaradır, bu isə hər iki mexanizmin təkbaşına olmasından pisdir. Sahibi seçin, sonra rəqib yolu təsadüfən deyil, qəsdən söndürün.

# who is configured to start something?
grep -v '^#' /etc/default/openvpn
systemctl list-units 'openvpn*'
nmcli -g connection.secondaries connection show 'Work Wi-Fi'

# NetworkManager: attach the tunnel to the base link by UUID
TUNNEL=$(nmcli -g UUID connection show 'Corp Tunnel')
nmcli connection modify 'Work Wi-Fi' +connection.secondaries "$TUNNEL"

Əgər çıxarılan paketlənmiş yoldursa, bunu düzgün ardıcıllıqla edin: AUTOSTART dəyərini none edin, yaradılan unitlərin yeni siyahını götürməsi üçün systemctl daemon-reload işə salın, sonra artıq istəmədiyiniz şablon instansiyasını söndürün. Yenidən yükləməni atlamaq köhnə unitləri aktiv saxlayır və bu, dəyişikliyin heç bir təsiri olmadığı kimi görünür.

Asılı qalan dayanma, cavabı məhdud olan ayrı bir problemdir. TimeoutStopSec systemd-in SIGKILL göndərməzdən əvvəl nə qədər gözlədiyini məhdudlaşdırır. Onu təyin etmək üçün düzgün yer drop-in faylıdır, çünki paketlənmiş uniti redaktə etmək dəyişikliyi növbəti yeniləmədə itirir.

Həqiqətən nəyin başladığını yoxlayın

Yenidən yükləyin və konfiqurasiya faylına güvənmək əvəzinə sübutları oxuyun. Tunelə sahib olan unit aktiv vəziyyət və yüklənməyə uyğun başlama vaxtı göstərəcək, VPN interfeysi isə siz daxil olmadan əvvəl mövcud olacaq.

systemctl is-enabled openvpn-client@office
systemctl status openvpn-client@office --no-pager
nmcli -f GENERAL.STATE,connection.secondaries connection show 'Work Wi-Fi'
ip -brief link show tun0

Buraya daha bir yoxlama aiddir: unitin ExecStart göstəricisinin düşündüyünüz binara baxdığını təsdiqləyin. Yerli olaraq kompilyasiya edilmiş müştəri və ya snap paketi çox vaxt açıq yol və ya snap run sarğısı tələb edir, çünki systemd sizin qabığınızın axtarış sırasını miras almır. command -v openvpn çıxışını unit faylı ilə müqayisə etmək bunu saniyələr içində həll edir.

Seçilmiş sahibi maşının qeydlərinə, profil adının yanına yazın. İtkin tuneli sazlayan növbəti şəxs müqayisəni təkrarlamaq əvəzinə həmin sətirdən başlayacaq.