OpenVPN istemciniz tek bir zaman aşımından sonra neden kapalı kalır

Pazartesi sabahı: cuma günü açılan tünel gitmiş, arayüz hâlâ listede ve günlükte kimsenin fark ettiğine dair hiçbir şey yok. Ana makine çevrimiçi, gösterge paneli yeşil ve hafta sonu boyunca gönderdiği her şey bunun yerine fiziksel arayüzden çıkmış. Burada iki bağımsız karar eksik: biri istemci sürecinin geçici bir hatadan sağ çıkıp çıkmayacağı, diğeri üstündeki bir şeyin süreç çıktıktan sonra onu yeniden başlatıp başlatmayacağı. Yalnızca birini düzeltmek diğer boşluğu açık bırakır.

İzlemenin iddia ettiğinden değil, birimin gerçekte ne yaptığından başlayın. systemctl status openvpn-client@office ve journalctl -u openvpn-client@office -n 50 çıkış nedenini ve istemcinin ayrılmadan önce yazdığı son satırı gösterir.

Süreç kimse fark etmeden çıktı

Hata olmadan kaybolan bir istemci genellikle bilerek çıkmıştır. Bu davranışı hizmet yöneticisi değil profil belirler: ping-exit karşı taraf yanıt vermeyi bırakır bırakmaz süreci sonlandırır, ping-restart ise süreci tutar ve içinde yeniden bağlanır. Oturum sınırları ve etkinlik dışı zamanlayıcılar dışarıdan aynı görüntüyü verir: tünel yok ve alarm yok.

İki ping yönergesi aynı profilde birlikte olamaz, bu yüzden birini seçin ve seçimi kaydedin. Sunucuya da bakın, çünkü kendi ping-exit istemcinin ne istediğinden bağımsız olarak oturumu kapatır ve bu kararı kimin verdiğini yalnızca sunucu günlüğü kaydeder.

ping-exit ile ping-restart arasında seçim

Kendini iyileştirmesi gereken bir dizüstü veya uzak saha için ping-restart seçin, ölü bir tünelin süreci durdurması ve başka bir şeyin tepki verebilmesi gereken durumlar için ping-exit ayırın. Sayılar ilişkiden daha az önemlidir: ping 10 ile ping-restart 60, bir sınamadan önce on saniye ve yeniden başlatmadan önce altmış saniye sessizlik demektir; bu, kayıplı bir mobil bağlantıda saldırgan, kablolu bir bağlantıda makuldür. Nedeni satırın yanına yazın, yoksa sonraki okuyucu varsayılan değerlerin bilinçli olduğunu düşünür.

Ardından çıkanın gerçekten süreç olduğunu doğrulayın. Tünel ölüyken etkin olduğunu bildiren bir birim başka bir arızadır ve aşağıda ele alınır.

Birimi gerçekten yeniden başlatan gözetim

systemd ana makinesinde en küçük kalıcı değişiklik tek bir drop-in dosyasıdır: Restart=on-failure ve RestartSec=10, /etc/systemd/system/[email protected]/restart.conf içinde. Drop-in yalnızca systemd kendi tanımlarını yeniden yüklediğinde okunur, bu yüzden ardından systemctl daemon-reload komutunu çalıştırın. Değerin yerine oturduğunu varsaymak yerine systemctl show -p Restart -p ExecMainStatus openvpn-client@office ile doğrulayın. Dosya adındaki örnek, birimin gerçekten yüklediği profil olmalıdır, bu yüzden office için yazılmış bir dosya openvpn-client@home için hiçbir şey yapmaz.

on-failure bir durumu yok sayar: durumu sıfır olan temiz bir çıkış. Bazı sökme yolları böyle biter, bu yüzden bir kılavuz sayfasının ifadesine güvenmek yerine kaydedilen durumu okuyun. İstemciniz sıfırla pes ederse Restart=always gerekir ve bedeli, gerçekten bozuk bir profilin başlatma hızı sınırı devreye girip günlük dolana kadar tekrar tekrar geri gelmesidir.

Restart=always bilinçli bir durdurmadan sonra da devreye girer. Bakım için systemctl stop kullanın ve siz çalışırken birimin kapalı kalması gerekiyorsa onu maskeleyin.

Tünel kapalıyken sızıntıyı yakalayın

Gözetim tüneli geri getirir; tünel yokken trafiğin dışarı çıkmasını engellemez. persist-tun cihazı ve rotalarını yeniden bağlanmalar arasında korur, bu da kullanışlıdır ve bir pencere açar. Cihaz yaşar, rotalar hâlâ ona yönelir ve paketler korumasız ve bildirimsiz dışarı akar. Bu bir ilke tercihidir, tarafsız bir varsayılan değil.

Bir ana makinenin korumasız paket göndermesine hiç izin verilmiyorsa, bunu yalnızca güvenlik duvarı garanti edebilir. Tünel arayüzüne ve VPN sunucusunun adresine izin verip geri kalan her şeyi düşüren bir çıkış kuralı, istemci öldükten sonra da geçerlidir ve istemcinin kendi yapılandırmasında istemcinin taşımadığı trafiği süzebilecek hiçbir şey yoktur.

İstemciyi bilerek durdurarak test edin. systemctl stop openvpn-client@office komutunu, ardından curl -m 5 https://example.com komutunu çalıştırın; bu, fiziksel bağlantı üzerinden başarılı olmak yerine başarısız olmalıdır. Başarı, güvenlik duvarı kuralının eksik olduğu veya fazla izin verdiği anlamına gelir.

Yeniden bağlanın, tünelin tekrar trafik taşıdığını doğrulayın ve ancak o zaman denetimi izlemeye ekleyin. cron üzerinden ip addr komutunu tun cihazı için sorgulamak en sık başarısız olan gözetimdir, çünkü persist-tun ile cihaz oturumdan daha uzun yaşar ve hiçbir şey taşınmazken sınama sağlıklı olduğunu bildirir.