A VPN lekapcsol, amikor a képernyő kialszik: melyik életciklus?

Az átvitel abban a pillanatban megáll, amikor a képernyő elsötétül, és a jelvény néhány másodperccel később követi. Három különböző dolog hozza létre ezt a képet: a kliensfolyamat korlátozódik, az útvonal tétlenné válik és elveszíti a leképezését, vagy az alkalmazás elveszít egy munkamenetet, amelyet az alagút soha nem vett észre. Mindegyiknek megvan a maga bizonyítéka, és minden javítás másik réteghez tartozik. Az alábbi sorrend egyetlen ellenőrzött teszttel választja el őket a beállítások átfésülése helyett.

Három hiba, amelyek azonosnak tűnnek

A korlátozott háttérfolyamat abbahagyja a keepalive-ok küldését, a másik fél pedig végül halottnak nyilvánítja az alagutat. Az útvonalon lévő tétlen leképezés lejárhat, miközben az eszköz alszik, így a visszatérő forgalom soha nem ér el egy klienst, amely még teljesen él. Az alkalmazás elveszítheti a saját kapcsolatát, miközben az alagút állva marad, ami hibapárbeszédet eredményez mögötte egy egészséges VPN-jelvénnyel. A felhasználó szemszögéből mindhárom úgy olvasható, hogy a VPN lekapcsolt a képernyő kialvásakor.

A megkülönböztetés azért fontos, mert a megoldások a gyakorlatban ellentmondanak egymásnak. A kliens mentesítése az energiakorlátozások alól az első esetet javítja, és semmit nem tesz egy lejárt leképezésért. A keepalive-ok meghosszabbítása a másodikat javítja, és a harmadikban pazarolja az akkumulátort, ahol eredetileg semmi hálózati nem volt hibás.

Hasonlítsa össze az aktív és a tétlen állapotot ellenőrzött körülmények között

Tartson mindent állandóan: ugyanaz az eszköz, ugyanaz a hálózat, ugyanaz a végpont, ugyanaz az alkalmazás. Zárja le a képernyőt egy rövid, rögzített időközre, és jegyezzen fel három megfigyelést: jelenti-e a kliens a kapcsolat bontását, működik-e egy friss kérés feloldáskor, és folytatódott-e a meglévő átvitel. Ezután ismételje meg egy futó keepalive vagy rendszeres kérés mellett, és hasonlítsa össze a két futást. Két futás között megváltoztatott egyetlen változó többet ér egy hét anekdotikus jelentésnél.

Az időzítés a jegyzőkönyv része. A kilencven másodperc utáni lekapcsolás leképezésre vagy keepalive-intervallumra utal, míg a zárás pillanatában történő lekapcsolás folyamat-felfüggesztésre mutat. Jegyezze fel a kiváltó okot és az intervallumot is, mert a következő kísérletnek kell valami, amihez hasonlíthat.

Olvassa el a platform háttérszabályzatát

Androidon a VPN-szolgáltatás életciklusa a platform része, és az always-on meg a block-without-VPN külön kapcsolók, külön hatásokkal. Egy nem always-on kliens leállítható, amikor a rendszer visszaveszi az erőforrásokat, és ezen egyetlen alkalmazásbeállítás sem változtat. Az iOS saját háttérkorlátokat alkalmaz az alagút-szolgáltatóra, és a dokumentált viselkedés eltér egy asztali daemontól, amely egyszerűen tovább fut. A kérdéses komponens platformdokumentációját olvassa, ne egy általános akkumulátor-optimalizálási útmutatót.

A felügyelt eszközök még egy réteget adnak hozzá. Egy szabályzat felülírhat egy személyes beállítást, így a működőnek tűnő változás a következő szabályzatfrissítéskor visszaáll. Használja a szervezet által támogatott kivételi folyamatot, ha az igény valós, és írja le, miért létezik a kivétel.

Mit tesz az eszköz ébredés után

Az automatikus újracsatlakozás nem ugyanaz, mint a forgalom blokkolása a rés alatt. Ellenőrizze mindkettőt: visszatér-e az alagút, és védtelenül ment-e ki egy alkalmazás, amely a rés alatt küldeni próbált. Az a kliens, amely két másodperc alatt újracsatlakozik, de az elsőben kiszivárogtat egy DNS-lekérdezést, rossz hibaszabályzattal rendelkezik egy munkaeszközhöz. Teszteljen ártalmatlan kérésekkel és egy Ön által ellenőrzött célponttal.

Az alkalmazás helyreállítása a harmadik kérdés. A visszatérő alagút nem javít meg egy lejárt SSH-munkamenetet, és a felhasználók gyakran ezt a munkamenet-vesztést jelentik VPN-hibaként. Tartsa együtt a jelentésben a kiváltó okot, a kliens buildjét és a pontos időzítést, mert ez a kombináció választja el a kiszámítható képernyő-kialvási életciklust egy szervertől, amely az eszköztől függetlenül hibázik.