VPN padá při vypnutí obrazovky: který životní cyklus?

Přenos se zastaví ve chvíli, kdy obrazovka ztmavne, a odznak ho o několik sekund následuje. Tři různé věci vytvářejí tento obrázek: proces klienta se omezí, cesta přejde do nečinnosti a ztratí své mapování, nebo aplikace ztratí relaci, které si tunel nikdy nevšiml. Každá má své důkazy a každá oprava patří jiné vrstvě. Pořadí níže je odděluje jedním řízeným testem místo plošného procházení nastavení.

Tři poruchy, které vypadají stejně

Omezený proces na pozadí přestane posílat keepalive a protějšek nakonec prohlásí tunel za mrtvý. Nečinné mapování na cestě může vypršet, zatímco zařízení spí, takže zpětný provoz se nikdy nedostane ke klientovi, který je stále naprosto živý. Aplikace může ztratit vlastní spojení, zatímco tunel zůstává nahoru, což vytvoří chybový dialog se zdravým odznakem VPN v pozadí. Z pohledu uživatele se všechny tři čtou jako VPN, která spadla při vypnutí obrazovky.

Rozdíl je důležitý, protože se nápravy v praxi navzájem vylučují. Vynětí klienta z energetických omezení opraví první případ a pro vypršené mapování neudělá nic. Prodloužení keepalive opraví druhý a ve třetím plýtvá baterií, kde od začátku nebylo nic síťového špatně.

Porovnejte aktivní a nečinný stav pod kontrolou

Držte vše konstantní: stejné zařízení, stejná síť, stejný koncový bod, stejná aplikace. Zamkněte obrazovku na krátký pevný interval a poznamenejte tři pozorování: zda klient hlásí odpojení, zda při odemčení funguje nový požadavek a zda se stávající přenos obnovil. Potom to zopakujte s běžícím keepalive nebo pravidelným požadavkem a oba běhy porovnejte. Jedna proměnná změněná mezi dvěma běhy vydá víc než týden anekdotických zpráv.

Čas patří do záznamu. Pád po devadesáti sekundách zavání mapováním nebo intervalem keepalive, zatímco pád v okamžiku zamknutí ukazuje na pozastavení procesu. Zapište spouštěč i interval, protože další pokus potřebuje něco k porovnání.

Přečtěte si zásady platformy pro práci na pozadí

V Androidu je životní cyklus služby VPN součástí platformy a always-on a block-without-VPN jsou samostatné přepínače s odlišnými účinky. Klient, který není always-on, může být zastaven, když systém získá zpět prostředky, a žádné nastavení v aplikaci to nezmění. iOS uplatňuje na poskytovatele tunelu vlastní omezení na pozadí a dokumentované chování se liší od démona na počítači, který prostě běží dál. Čtěte dokumentaci platformy k dotyčné komponentě, ne obecného průvodce optimalizací baterie.

Spravovaná zařízení přidávají další vrstvu. Zásada může přepsat osobní nastavení, takže změna, která vypadá funkčně, se vrátí při dalším obnovení zásad. Pokud je požadavek skutečný, použijte organizací podporovaný proces výjimky a zapište, proč výjimka existuje.

Co zařízení dělá po probuzení

Automatické opětovné připojení není totéž jako blokování provozu během mezery. Zkontrolujte obojí: zda se tunel vrátí a zda aplikace, která se během mezery pokusila odeslat, neodešla nechráněná. Klient, který se znovu připojí za dvě sekundy, ale v první propustí dotaz DNS, má pro pracovní zařízení špatnou politiku selhání. Testujte neškodnými požadavky a cílem, který ovládáte.

Obnova aplikace je třetí otázka. Tunel, který se vrátí, neopraví relaci SSH, které vypršel čas, a uživatelé tuto ztrátu relace často hlásí jako selhání VPN. Držte spouštěč, sestavení klienta a přesný čas pohromadě ve zprávě, protože tato kombinace odděluje předvídatelný životní cyklus vypnutí obrazovky od serveru, který selhává nezávisle na zařízení.