OpenVPN, dizüstü bilgisayar uyandıktan sonra neden ölür?

Uyku, OpenVPN oturumunu öldürüp tun0'ı geride bırakabilir. Tüneli test edin, ardından birimi cihazdan değil systemd uyku kancasından yeniden başlatın.

Makineyi uykuya alın, uyandırın ve ardından herhangi bir yapılandırmaya dokunmadan önce şu sırayla üç şeyi kontrol edin: tun0 hâlâ var mı, dahili bir adrese giden yol hâlâ onu seçiyor mu ve sunucu bu peer'ı hâlâ listeliyor mu. Yol başka yeri gösterirken uykudan sağ çıkan cihaz bir kalıntıdır, tünel değil. Yol doğruyken trafik yine de ölüyorsa, arıza tünelin üzerindedir ve istemciyi yeniden başlatmak bunu değiştirmez. Yeniden başlatmayı otomatikleştirmek, ancak elle yapılan bir test bu üç durumdan hangisine sahip olduğunuzu gösterdikten sonra anlamlıdır.

ip -br address show tun0
ip route get 10.20.0.10
journalctl -u openvpn-client@office -b --no-pager | tail -30

Otomatikleştirmeden önce uyanmayı yeniden üretin

Uyku, şifreli oturumu cihazı kaldırmaktan daha sık sonlandırır. Tüneli canlı tutan UDP akışı durur, sunucu peer'ı düşürebilir ve istemci ya bunu fark edip yeniden bağlanır ya da arkasında hiçbir şey olmayan bir arayüzü korur. Arayüz kontrolü tek başına çok az şey kanıtlar, çünkü eski bir cihaz, çalışan bir cihazla tamamen aynı görünür paketler içinden geçmek zorunda kalana kadar. Yol sorgusunu ve tünelden geçen bir gerçek isteği çalıştırın, ardından uyanma anının çevresindeki günlüğü okuyun.

İstemci kendi kendine dönerse, bir kanca güvenilirlik yerine fazladan telaş ekler. Hiç toparlanmazsa, otomasyon dürüst çözümdür.

systemd uyku kancası gerçekte nerede yaşar

Birçok eski kılavuz /etc/pm/sleep.d dizinini gösterir; bu, pm-utils'e ait bir dizindir ve systemd tabanlı uyku ona hiç danışmaz. systemd kancaları /usr/lib/systemd/system-sleep/ ve /etc/systemd/system-sleep/ içinden okur, önce aşamayı sonra işlemi iletir, bu yüzden pre ve post bir kancanın dallandığı tek değerlerdir. Yerel kopyayı paketlenmiş dosyayı düzenlemek yerine /etc altında tutun ve betiğin geçişin ortasında root olarak çalıştığını unutmayın, bu yüzden hızlı dönmelidir.

#!/bin/sh
case "$1" in
  post)
    systemctl --no-block try-restart [email protected]
    ;;
esac
exit 0

try-restart bir birime yalnızca zaten etkinken dokunur, bu yüzden bilerek kapattığınız tünel uyanma boyunca kapalı kalır. --no-block kancanın istemci görüşürken beklemesini engeller, bu da ağ henüz kalkmamışken önemlidir. İki bayrak birlikte, tüm uyanma dizisini tutmak yerine sessizce başarısız olan bir kanca anlamına gelir. Birim zaten durdurulmuşsa hiçbir şey olmaz, ki orada istediğiniz sonuç tam olarak budur.

Hizmeti geri yükleyin, tun0'a dokunmayın

tun0 bileşenini elle indirmek, arka plan sürecini artık sahip olmadığı bir arayüzü denetlerken bırakır ve sonraki durum değişikliği kafa karıştırıcı hatalar üretir. Arayüz yerine hizmeti veya bağlantı profilini hedefleyin; önce birimin tam adını kontrol edin, çünkü dağıtım paketleri, OpenVPN 3 ve NetworkManager hepsi farklı olanları seçer. Bir NetworkManager profili, o bağlantı döngüye sokulduğunda geri gelir, bu yüzden orada hedef systemd birimi değildir. Mekanizma ne olursa olsun, elle doğruladığınız aynı eylem olmalıdır.

Yeniden başlatma, istemcinin bağlanırken ittiği yolları yeniden kurar. Çoğu uyanma bunu ister. Kendi yollarınızı eklediğiniz makine istemez, bu yüzden kurtarmanın onları geri koyduğunu varsaymak yerine yeniden kontrol edin ve sonraki uyanmanın bulabileceği bir yere yazın.

Kontrol edemediğiniz zamanlamayla başa çıkın

Kablosuz ilişkilendirme ve DHCP genellikle kanca çalıştıktan sonra tamamlanır, bu yüzden sunucuya giden bir yol henüz yokken yeniden başlatma başarısız olabilir. O adresi kısa süre bekleyin, bir kez daha deneyin ve sonucu günlüğe yazın.

Ad çözümleme ayrı bir yarıştır, çünkü masaüstü ağ yığını tünel zaten ayaktayken DNS'i geri yükleyebilir. Aramaları çalışan bir yoldan çıkarsamak yerine resolvectl query internal.example ile ayrı ayrı test edin. Doğru yönlendiren ve hiçbir şeyi çözemeyen bir tünel DNS sorunudur, kanca sorunu değildir.

Kancanın kararını günlüğe aşamayı, birimin adını ve sonucu yazarak görünür tutun. Makinenin notlarına hangi uyanma testini çalıştırdığınızı yazın, böylece çalışan bir kurtarma şanslı olandan ayırt edilebilsin. Hizmeti geri getiren en az rahatsız edici eylemi seçin ve kendi kendine toparlanan istemcinin bunu yapmasına izin verin. Tam yeniden başlatma, sürmekte olan oturumları düşürür; bu, günde birkaç kez uyanan bir dizüstü bilgisayarda gerçek bir maliyettir.

İlgili makaleler