OpenVPN keepalive mı systemd yeniden başlatması mı: hangisi kurtarır?
Sessiz bir eş, ölü bir süreç ve kullanılamaz bir uygulama üç farklı arızadır. keepalive'ı OpenVPN'e, süreci systemd'ye bırakın ve her durumu test edin.
Bir tünelle ilgili üç farklı şey ters gidebilir ve bunlar üç farklı tepki gerektirir. Eş yanıt vermeyi bırakır, daemon süreci ölür veya tünelin arkasındaki uygulama hizmet vermeyi bırakır. Bunlardan herhangi birinde hizmeti yeniden başlatan bir yapılandırma dikkatli bir denetim değildir; ilgisiz arızalara uygulanan tek bir kaba eylemdir. Her mekanizmanın gerçekte neyi gözlemleyebildiğini karşılaştırmak iş bölümünü açık hale getirir.
Tek gibi görünen üç arıza
Eş sessizliği, diğer ucun göndermeyi bıraktığı anlamına gelir ve OpenVPN kalp atışının sahibi olduğu için bunu kendisi algılayabilir. Süreç ölümü, daemonun çıktığı anlamına gelir; bunu hizmet yöneticisi fark eder, OpenVPN edemez. Uygulama arızası, tünelin iyi olduğu ve arkasındaki bir şeyin iyi olmadığı anlamına gelir ve diğer iki mekanizmanın bunu bilmesinin hiçbir yolu yoktur. Her biri farklı bir tepki gerektirir ve hiçbiri tünelin ayakta olduğunu fark etmekle aynı şey değildir.
Bunlar farklı katmanlardan gelen farklı sinyallerdir ve her birinin tahmin etmeden harekete geçebilecek bir sahibi vardır. Bunları karıştırmak, yorumlayamadığı belirtilerde yeniden başlayan bir sistem üretir.
Herhangi bir zamanlayıcıyı değiştirmeden önce üç durumu yazın. Listenin kendisi genellikle bir mekanizmadan üçünü de kapsamasının istendiğini gösterir.
keepalive aslında neye açılır
keepalive yönergesi bir kısaltmadır ve açılımı moda göre değişir. Bir sunucuda keepalive 10 60 her on saniyede bir yerel ping'e, 120 saniyelik yerel yeniden başlatma zaman aşımına ve istemcilere gönderilen 10 ile 60 değerlerine dönüşür. Sunucu zaman aşımı, istemcinin sunucu pes etmeden önce yeniden başlama şansı bulması için bilerek iki katına çıkarılır. Profildeki kısaltmayı değil, çalışan yapılandırmadaki açılmış biçimi okuyun.
O iki katına çıkarma, altmış saniye sonra iki ucun da yeniden başladığını iddia eden her açıklamanın neden yanlış olduğunun cevabıdır. Ayrıca bir yol bozulduğunda iki ucun neden aynı ritimde dalgalanmadığını da açıklar.
Kalp atışı OpenVPN eş trafiğidir, herhangi bir genel sunucuya yapılan ICMP yoklaması değildir. Bir yanıt yalnızca tünelin uzak ucunun yaşadığını kanıtlar. Kullanıcının gerçekten ihtiyaç duyduğu veritabanı veya web hizmeti hakkında hiçbir şey söylemez.
Restart=on-failure neyi izlemez
Bir geçersiz kılma eklemeden önce kurulu unit dosyasını okuyun. Restart=on-failure belgelenmiş süreç arızası koşullarına yanıt verir, bu da bağlantı durumunu izlemekle aynı şey değildir. İçsel bir yeniden bağlanma başladığı için tetiklenmez ve temiz bir çıkışın anlamı bir çökmeden farklıdır.
Bu ayrım önemlidir çünkü içsel bir yeniden başlatma aynı süreci canlı tutar. Unit hiçbir şey görmez, tünel kendi kendine toparlanır ve doğru sonuç budur.
RestartSec ve başlatma sınırlarını bilerek ayarlayın, yoksa bir çökme döngüsü ağ geçidini döver ve gerçek hatayı yeniden başlatma mesajlarının altına gömer. Tetiklenen bir yeniden başlatma sınırı unit dosyasını başarısız bırakır, bu görünür, sınırsız bir döngü ise görünmez.
ping-restart ve ping-exit birbirinin yerine kullanılamaz
ping-restart OpenVPN'in içsel yeniden başlatmasını tetikler ve süreci korur. ping-exit aynı tür zaman aşımında süreci sonlandırır, bu da kararı hizmet yöneticisine bırakır. Birbirlerini dışlarlar ve ikincisini seçmek toparlanmanın sahibini değiştirir. Fark, yeniden denemeye kimin karar verdiği ve denemede ne kadar durumun hayatta kaldığıdır.
Zaman aşımında çıkmayı seçerseniz, unitin eşleşen bir yeniden başlatma politikasına ve çıkış durumu işlemesine ihtiyacı vardır, yoksa bir canlılık arızası kalıcı bir durma gibi görünür. Kalıcılık seçenekleri arayüzleri ve rotaları içsel bir yeniden başlatma boyunca koruyabilir ama süreç çıkışı boyunca koruyamaz.
Her dağıtım için tek bir yaşam döngüsü seçin ve nedenini yazın. İki yönergeyi de taşıyan bir profil, karar vermemiş bir profildir.
Her arızayı kendi durumu olarak test edin
Onaylanmış bir pencerede sessiz bir eşi, öldürülmüş bir daemonu ve kullanılamayan bir uygulamayı simüle edin, sonra hangi toparlanmanın tetiklendiğine bakın. Sessiz bir eş içsel bir yeniden bağlanma, öldürülmüş bir süreç unit yeniden başlatması üretmeli, uygulama kesintisi ise bunların hiçbirini üretmemelidir. İki durum aynı eylemi üretiyorsa sahiplik hâlâ karışıktır.
Tekrarlanan toparlanma da bir onarım değildir. Reddedilen kimlik bilgileri veya etkin bir adı paylaşan iki istemci birbirinin yerini almaya devam eder ve daha hızlı zamanlayıcılar o dalgalanmayı yalnızca hızlandırır.