systemd VPN hizmetini durduruyor: Type= değerini istemciyle eşleştirin

Açılışta başlayan VPN birimi, Type= istemcinin ömrüyle eşleşmediğinde etkin olmaktan çıkar. Türü eşleştirin, sahipliği düzeltin ve hizmeti tünelden sonra sıralayın.

Birimler doğru görünebilir, systemctl start başarı bildirebilir ve on saniye sonra hizmet etkin değil durumunda bekler. Ya da başlatma sınırı onu durdurana kadar her yarım dakikada bir yeniden başlar. İki davranışın hiçbiri ağ arızası değildir: birim, istemcinin gerçekte yaptığı işle uyuşmayan bir süreç ömrü tanımlar. İstemci fork edip çıkabilir ya da oturumu yapılandırıp hemen çıkabilir.

Başarılı bir başlatmadan saniyeler sonra birim neden etkin olmaktan çıkar

systemd durumu kendi başlattığı süreçten çıkarır, bu yüzden Type= o süreç hakkında bir iddiadır, belge değil. Type=simple ile birim komut çalıştığı sürece etkin sayılır ve komut döndüğünde etkin olmaktan çıkar. Bağlantıyı bir yardımcıya devredip çıkan istemci bu yüzden tünel ayakta olsa bile çökme gibi görünür. Ardından günlük, bozuk bir ikili gibi okunan bir başlatma ve durdurma deseni gösterir.

Ağ yapılandırmasına dokunmadan önce birim türünü istemcinin davranışının yanında okuyun.

İstemciye uyan türü seçin

İki desen satıcı CLI'lerinin çoğunu kapsar: oturumu yapılandırıp çıkan bir komut ve dönmeden önce yardımcıyı fork eden bir komut. Her biri farklı bir birim biçimi gerektirir.

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/bin/protonvpn-cli connect -f
ExecStop=/usr/bin/protonvpn-cli disconnect

oneshot ile RemainAfterExit=true komut döndükten sonra birimi etkin tutar, bu da yapılandır ve çık desenine uyar ve durdurma komutu hizmete temiz bir kapanış verir. Fork eden istemci aynı biçimi korur ama systemd'nin alt süreci izlemesi için Type=forking gerekir. Restart=on-failure, RestartSec=30 ve sonlu bir StartLimitBurst ayarlayın, böylece sağlayıcı kesintisi hatayı gömen bir yeniden başlatma döngüsüne dönüşmesin.

Denetlenen bir istemcinin daemonlaşmasına asla izin vermeyin

systemd dışındaki denetleyiciler aynı duvara çarpar. Daemonlaşmış bir istemciyi başlatan runit çalıştırma betiği hemen denetleyiciye döner, o da bu dönüşü çökme olarak okuyup bir kopya daha başlatır. Her denetleyici ön plandaki sürece sahip olmayı bekler, tıpkı sshd -D önde kaldığı gibi. Denetlenen komutlarda daemon bayrağını kaldırın ve arka plan işini denetleyiciye bırakın. Tünel oluşmadan dönen sarmalayıcı betikler de aynı karışıklığa yol açar.

Kendini ayıran bir süreç, onu izlemesi gereken her şey için görünmezdir.

Oturum biter ve tüneli de yanında götürür

Bir masaüstü oturumu başlattığı istemciye sahiptir. Oturumu kapatın, oturum veriyolu kaybolur ve tüneli de götürür; grafik istemcinin bağlantısının son pencere kapanınca sık sık düşmesinin nedeni budur. Sunucular kendi kendine kalkan bir sistem birimi veya NetworkManager profili kullanmalıdır. Kullanıcı birimi yalnızca tünelin oturum kapanışıyla bitmesi gerektiğinde anlamlıdır, bu yüzden onu grafik oturumun hedefine bağlayın ve bunu açıklamasında belirtin.

Hizmet kullanıcısı aynı sorunun diğer yarısıdır. root'a ait ve kipi 0600 olan bir anahtar, başka bir hesap altında çalışan bir birim için okunamaz, sudo kabuğunuzda ne başarmış olursa olsun.

systemctl cat openvpn-server@work
sudo chown -R openvpn:network /etc/openvpn/server
sudo find /etc/openvpn -type f -perm /077 -ls

Bağımlıları adres oluştuktan sonra sıralayın

Bir daemon henüz oluşturulmamış bir tünel adresine bağlandığında Cannot assign requested address ile çıkar. Onarım, yeniden deneme döngüsü değil açık bir sıralamadır.

[Unit]
After=network.target [email protected]
Requires=sys-devices-virtual-net-wg0.device

After= işleri sıralar, aygıt birimindeki Requires= ise bağımlıyı arayüzün varlığına bağlar; bu, yalnızca ağ hedefini beklemekten daha güçlüdür. Düzenlemeden sonra yöneticiyi yeniden yükleyin ve bağımlı hizmeti yeniden başlatın, sonra sıranın işlediğini varsaymak yerine günlüğünü okuyun. İstemcinin çıktısını StandardOutput=journal veya bir günlük seçeneğiyle günlüğe gönderin, çünkü kimsenin açmadığı bir dosyaya yazan denetlenen istemci hiç başlamamış olanla tamamen aynı görünür.

Sonra bir kez yeniden başlatın ve tünel aygıtı göründükten sonra birimin etkin olduğunu doğrulayın. Yalnızca systemctl start ile doğrulanan bir onarım, düzeltmesi gereken açılış sırasını test etmemiştir.

İlgili makaleler