Ekran kapanınca VPN neden düşer: hangi yaşam döngüsü?
Kilitli bir ekran istemciyi askıya alabilir, bir eşlemeyi sona erdirebilir veya bir uygulama oturumunu öldürebilir. Tek bir kontrollü test, herhangi bir ayar değişmeden önce bunları ayırır.
Aktarım, ekranın karardığı anda durur ve rozet birkaç saniye sonra gelir. Bu görüntüyü üç farklı şey üretir: istemci süreci kısıtlanır, yol boşta kalıp eşlemesini kaybeder veya uygulama tünelin hiç fark etmediği bir oturumu kaybeder. Her birinin kendi kanıtı vardır ve her düzeltme farklı bir katmana aittir. Aşağıdaki sıra, tüm ayarları gözden geçirmek yerine tek bir kontrollü testle bunları ayırır.
Aynı görünen üç arıza
Kısıtlanmış bir arka plan süreci keepalive göndermeyi bırakır ve karşı taraf sonunda tüneli ölü ilan eder. Yoldaki boşta bir eşleme, cihaz uyurken sona erebilir; böylece dönüş trafiği hâlâ tamamen canlı olan bir istemciye hiç ulaşmaz. Uygulama, tünel ayaktayken kendi bağlantısını kaybedebilir; bu da arkasında sağlıklı bir VPN rozeti olan bir hata penceresi üretir. Kullanıcı açısından üçü de ekran kapanınca VPN düştü diye okunur.
Ayrım önemlidir çünkü çözümler pratikte birbirleriyle çelişir. İstemciyi güç kısıtlamalarından muaf tutmak ilk durumu düzeltir ve süresi dolmuş bir eşleme için hiçbir şey yapmaz. Keepalive sürelerini uzatmak ikinciyi düzeltir ve üçüncüde pil harcar; orada baştan itibaren ağla ilgili hiçbir şey yanlış değildi.
Etkin ve boşta durumu kontrollü koşullarda karşılaştırın
Her şeyi sabit tutun: aynı cihaz, aynı ağ, aynı uç nokta, aynı uygulama. Ekranı kısa ve sabit bir aralık için kilitleyin ve üç gözlem yazın: istemci bir kopma bildiriyor mu, kilit açıldığında yeni bir istek çalışıyor mu ve mevcut aktarım devam etti mi. Ardından çalışan bir keepalive veya düzenli istek varken tekrarlayın ve iki çalıştırmayı karşılaştırın. İki çalıştırma arasında değiştirilen tek bir değişken, bir haftalık anekdot raporundan daha değerlidir.
Zaman kayda aittir. Doksan saniye sonraki düşüş bir eşleme veya keepalive aralığını düşündürürken, kilit anındaki düşüş süreç askıya alınmasına işaret eder. Hem tetikleyiciyi hem aralığı yazın, çünkü bir sonraki denemenin karşılaştıracak bir şeye ihtiyacı var.
Platformun arka plan ilkesini okuyun
Android'de VPN hizmetinin yaşam döngüsü platformun parçasıdır ve always-on ile block-without-VPN ayrı etkileri olan ayrı anahtarlardır. Always-on olmayan bir istemci, sistem kaynakları geri aldığında durdurulabilir ve uygulamadaki hiçbir ayar bunu değiştirmez. iOS tünel sağlayıcısına kendi arka plan sınırlarını uygular ve belgelenen davranış, öylece çalışmaya devam eden bir masaüstü arka plan hizmetinden farklıdır. Söz konusu bileşen için platform belgelerini okuyun, genel bir pil optimizasyonu kılavuzunu değil.
Yönetilen cihazlar bir katman daha ekler. Bir ilke kişisel bir ayarı geçersiz kılabilir, bu yüzden çalışıyor gibi görünen bir değişiklik bir sonraki ilke yenilemesinde geri döner. Gereksinim gerçekse kuruluşun desteklediği istisna sürecini kullanın ve istisnanın neden var olduğunu yazın.
Cihaz uyandıktan sonra ne yapar
Otomatik yeniden bağlanma, boşluk sırasında trafiği engellemekle aynı şey değildir. İkisini de kontrol edin: tünel geri dönüyor mu ve boşluk sırasında göndermeyi deneyen uygulama korumasız mı çıktı. İki saniyede yeniden bağlanan ama ilk saniyede bir DNS sorgusunu sızdıran istemci, iş cihazı için yanlış hata ilkesine sahiptir. Zararsız istekler ve kontrol ettiğiniz bir hedefle test edin.
Uygulama kurtarma üçüncü sorudur. Geri dönen bir tünel, süresi dolmuş bir SSH oturumunu onarmaz ve kullanıcılar bu oturum kaybını sıklıkla VPN arızası olarak bildirir. Tetikleyiciyi, istemci derlemesini ve tam zamanı raporda birlikte tutun, çünkü bu bileşim öngörülebilir bir ekran kapanması yaşam döngüsünü, cihazdan bağımsız olarak başarısız olan bir sunucudan ayırır.