Systemd mi NetworkManager mı: açılışta VPN'i kim başlatıyor?

Aynı imajdan iki Ubuntu makinesi, tek bir VPN profili, oturum açılışında zıt sonuçlar: birinde masaüstü görünmeden tünel çoktan ayakta, diğerinde hiç kalkmıyor. Burada değişken profil değil. Fark, üç bileşenden hangisine onu başlatma talimatı verildiğinde, ve bu üçü tek bir anahtarı paylaşmıyor.

Yan yana karşılaştırmak tahmin etmekten hızlıdır. Her biri tanınabilir bir şekilde başarısız olur, karşılaştırmayı değerli kılan da budur.

Üç farklı tetikleyicili üç başlatıcı

Paketlenmiş openvpn servisi en eski yoldur. Init betiği otomatik başlatma listesini /etc/default/openvpn dosyasından okur. Bu liste yorum satırına alınmış ya da boş bırakılmışsa, betik sizin eklediğiniz tek yapılandırma yerine o dizinde bulduğu her yapılandırmayı başlatır. Tek bir tünel için eklenen tek dosya sessizce birkaçını kaldırabilir.

İnsanların yanlış yapılandırdığı ikinci satırdır. NetworkManager içe aktarılan profili tutar ve onu başlatır, ancak yalnızca başka bir bağlantının ikincil bağlantısı olarak, yani tetikleyici VPN'e değil ağ bağlantısına aittir.

Kurulum maliyetini ve kapsamı karşılaştırın

Init betiği yolu tek satıra mal olur ve makinedeki her yapılandırmayı kapsar. Bu bir yönlendirici için doğru, farklı ağlara bağlanan bir dizüstü için yanlıştır. NetworkManager yolu bir UUID aramasına mal olur ve tüneli tek bir temel bağlantıya bağlar. İş yerinin SSID'sinde kalkar, otel ağında kapalı kalır.

Elle yazılmış unit en pahalıdır ve diğer servislere göre sıralama dahil en fazla denetimi verir. Belirleyici etken kapsamdır. Makinede tek ağ ve tek tünel varsa, paketlenmiş servis dürüst ve öngörülebilirdir. Tünel belirli bir Wi-Fi ağını izlemek zorundaysa, ek betik olmadan bu koşulu ifade eden üçünden yalnızca ikincil bağlantıdır.

Tek bir sahip seçin ve diğerlerini kaldırın

İki sahip tarafından başlatılan bir profil, açılışlar arasında değişen bir zamanlama üretir, bu da mekanizmaların her birinin tek başına olmasından kötüdür. Sahibi seçin, sonra rakip yolu kazara değil bilerek kapatı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"

Emekliye ayrılan paketlenmiş yolsa, doğru sırayla yapın: AUTOSTART değerini none yapın, üretilen unit'lerin yeni listeyi alması için systemctl daemon-reload komutunu çalıştırın, ardından artık istemediğiniz şablon örneğini devre dışı bırakın. Yeniden yüklemeyi atlamak eski unit'leri etkin bırakır ve değişikliğin hiçbir etkisi olmamış gibi görünür.

Askıda kalan durdurma, sınırlı yanıtı olan ayrı bir sorundur. TimeoutStopSec, systemd'nin SIGKILL göndermeden önce ne kadar bekleyeceğini sınırlar. Bunu ayarlamak için doğru yer drop-in dosyasıdır, çünkü paketlenmiş unit'i düzenlemek değişikliği bir sonraki yükseltmede kaybeder.

Gerçekte neyin başladığını doğrulayın

Yeniden başlatın ve yapılandırma dosyasına güvenmek yerine kanıtları okuyun. Tünele sahip unit etkin durumu ve açılışla eşleşen bir başlangıç zaman damgası gösterir, VPN arayüzü siz oturum açmadan önce var olur.

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 bir kontrol daha sığar: unit'in ExecStart değerinin düşündüğünüz ikili dosyayı gösterdiğini doğrulayın. Yerelde derlenmiş bir istemci ya da snap paketi çoğu zaman açık bir yol veya snap run sarmalayıcısı gerektirir, çünkü systemd kabuğunuzun arama sırasını devralmaz. command -v openvpn çıktısını unit dosyasıyla karşılaştırmak bunu saniyeler içinde çözer.

Seçilen sahibi makinenin notlarına, profil adının yanına yazın. Eksik tüneli ayıklayacak bir sonraki kişi karşılaştırmayı yinelemek yerine o satırdan başlar.