OpenVPN up'ta hizmeti yeniden başlatmak: hooks tun0.device'ı yener

Bağımlı bir hizmeti tun0.device'a bağlamak tünele abone olmak gibi görünür ve öyle değildir. Aygıt birimi arayüzün var olduğunu yansıtır; bu, başarısız bir bağlantı ve ardından gelen yeniden bağlanma boyunca doğru kalabilir. Hizmet o zaman yanlış anda ya da hiç harekete geçer; arayüzün arada kaybolup kaybolmadığına bağlıdır. Gerçekten önemsediğiniz olayı tanımlayan kanca, OpenVPN'in çağırdığı kancadır, systemd'nin çıkarsadığı değil.

Tetikleyiciyi seçmeden önce hizmetin hangi koşula ihtiyacı olduğuna karar verin, çünkü üç aday birbirinin yerine geçmez.

Aygıt birimi gerçekte neyi izler

systemd, çekirdeğin bir ağ arayüzüne bakışından bir aygıt birimi oluşturur; bu yüzden tun0.device arayüz göründüğünde etkin, kaldırıldığında etkin olmaz. persist-tun ile yumuşak bir yeniden başlatma arayüzü yerinde tutar, böylece birim asla titreşmez ve ona bağlı hiçbir şey tetiklenmez. Kalıcılık olmasa bile birim yollar, DNS veya uzak uç yanıt veriyor mu konusunda hiçbir şey söylemez.

Bu onu 'VPN hazır' için kötü bir vekil yapar. Yalnızca yerel adrese ihtiyaç duyan bir dinleyici arayüzün varlığıyla tatmin olabilir; uzak ağdaki bir uygulamayı çağıran hizmet ise yollar ve erişilebilirlik gerektirir, ki aygıt birimi bunları ifade edemez.

up, route-up ve up-restart farklı anlamlara gelir

up, TUN/TAP aygıtı açıldıktan ve arayüz yapılandırıldıktan sonra çalışır; bu, atanan adresi bağlayan dinleyici için doğru andır. route-up, yollar kurulduktan sonra, yapılandırılmış herhangi bir yol gecikmesine tabi olarak çalışır ve yollar aşamasının tamamlanmasını gerektiren işlere uygundur. İkisi de uzak uygulamanın yanıt verdiğini kanıtlamaz. Aralarında seçim yapmak, hizmetin neye ihtiyacı olduğu sorusudur, hangi kancanın daha bitmiş göründüğü değil.

persist-tun ile yeniden başlatmalar aygıtı yeniden kullanır, bu yüzden up-restart ayarlanmadıkça up yeniden çalışmaz. Bu seçenek, up betiğini belgelenmiş yeniden başlatma yaşam döngüsü için etkinleştirir ve ortamı ilk başlatmaya kıyasla azaltılmıştır. Tam ortamı varsayan bir betik ilk bağlantıda çalışır ve sonrakinde başarısız olur.

Eylemi beklemeden gönderin

systemctl restart'ı eşzamanlı çağıran bir kanca, sırası tüneli bekleyen bir birimle kilitlenebilir. systemctl --no-block try-restart vpn-dependent.service işi kuyruğa alır ve döner; bu, kancanın tepki verdiği bağlantıyı engellemesini önler. try-restart yalnızca çalışan bir birim üzerinde etkilidir, restart ise etkin olmayanı da başlatır; alışkanlıkla değil, bilinçli seçin.

Kuyruğa almak doğrulama değildir. Kanca iş kabul edilir edilmez başarı döndürür, bu yüzden kontrol hedef birimin günlüğünde veya gerçek dinleyici durumunda yapılmalıdır.

Yeniden başlatma politikası kancada değil, birimde yaşar

RemainAfterExit=yes olan oneshot birim, komutu bittikten sonra da etkin kalır ve ikinci başlatma isteği hiçbir şey yapmaz çünkü systemd onu zaten başlatılmış sayar. Bu, etrafında tasarım yapılacak bir özelliktir; tekrarlanan başlatma çağrılarıyla etrafından dolaşılacak bir kusur değildir. Eylem her bağlantıda çalışmak zorundaysa, birimin buna izin veren bir biçime ihtiyacı vardır.

After= birimleri sıralar ve BindsTo= ömürleri bağlar, ama hiçbiri 'VPN her yeniden bağlandığında bunu yeniden başlat' anlamına gelmez. Tünele bağlı bir birim tünel durduğunda durur; tünel geri geldiğinde kendini yeniden başlatmaz, meğer ki bir şey onu yeniden başlatsın.

Bir değil, üç yeniden bağlanmayı test edin

Soğuk önyükleme, tam istemci yeniden başlatması ve yumuşak yeniden bağlanma her biri farklı bir yolu çalıştırır. Eksik up-restart'ı, azaltılmış ortamı veya hiç etkin olmayan hale gelmemiş aygıt birimini ortaya çıkaran yumuşak yeniden bağlanmadır. Üçünü de çalıştırın ve iki yönü doğrulayın: tünel yukarı çıktığında hizmet harekete geçer ve Wi-Fi dolaşımı gibi ilgisiz bağlantı değişikliklerinde yeniden başlamaz.

Bağımlı hizmet kendi yönetim erişiminizi taşıyorsa bağımsız bir kurtarma yolu tutun. Bağlandığınız şeyi yeniden başlatan bir kanca, sizi dışarıda bırakabilecek bir değişikliktir.