VPN padá pri vypnutí obrazovky: ktorý životný cyklus?
Uzamknutá obrazovka môže pozastaviť klienta, nechať mapovanie vypršať alebo zabiť reláciu aplikácie. Jeden riadený test ich oddelí pred akoukoľvek zmenou nastavení.
Prenos sa zastaví v okamihu, keď obrazovka stmavne, a odznak ho o niekoľko sekúnd nasleduje. Tri rôzne veci vytvárajú tento obraz: proces klienta sa obmedzí, cesta prejde do nečinnosti a stratí svoje mapovanie, alebo aplikácia stratí reláciu, ktorú si tunel nikdy nevšimol. Každá má svoje dôkazy a každá oprava patrí inej vrstve. Poradie nižšie ich oddelí jedným riadeným testom namiesto plošného prechodu všetkými nastaveniami.
Tri poruchy, ktoré vyzerajú rovnako
Obmedzený proces na pozadí prestane posielať keepalive a protistrana nakoniec vyhlási tunel za mŕtvy. Nečinné mapovanie na ceste môže vypršať, kým zariadenie spí, takže spätná premávka sa nikdy nedostane ku klientovi, ktorý je stále úplne živý. Aplikácia môže stratiť vlastné spojenie, kým tunel stojí, čo vytvorí chybový dialóg so zdravým odznakom VPN za ním. Z pohľadu používateľa sa všetky tri čítajú ako VPN, ktorá spadla pri vypnutí obrazovky.
Rozdiel je dôležitý, pretože sa nápravy v praxi navzájom vylučujú. Vyňatie klienta z energetických obmedzení opraví prvý prípad a pre vypršané mapovanie neurobí nič. Predĺženie keepalive opraví druhý a v treťom plytvá batériou, kde od začiatku nebolo nič sieťové nesprávne.
Porovnajte aktívny a nečinný stav pod kontrolou
Držte všetko konštantné: rovnaké zariadenie, rovnaká sieť, rovnaký koncový bod, rovnaká aplikácia. Zamknite obrazovku na krátky pevný interval a zapíšte tri pozorovania: či klient hlási odpojenie, či pri odomknutí funguje nová požiadavka a či sa existujúci prenos obnovil. Potom to zopakujte s bežiacim keepalive alebo pravidelnou požiadavkou a oba behy porovnajte. Jedna zmenená premenná medzi dvoma behmi vydá viac ako týždeň anekdotických správ.
Čas patrí do záznamu. Pád po deväťdesiatich sekundách zaváňa mapovaním alebo intervalom keepalive, kým pád v okamihu zamknutia ukazuje na pozastavenie procesu. Zapíšte spúšťač aj interval, pretože ďalší pokus potrebuje niečo na porovnanie.
Prečítajte si zásady platformy pre prácu na pozadí
V Androide je životný cyklus služby VPN súčasťou platformy a always-on a block-without-VPN sú samostatné prepínače s odlišnými účinkami. Klient, ktorý nie je always-on, môže byť zastavený, keď systém získa späť prostriedky, a žiadne nastavenie v aplikácii to nezmení. iOS uplatňuje na poskytovateľa tunela vlastné obmedzenia na pozadí a dokumentované správanie sa líši od démona na počítači, ktorý jednoducho beží ďalej. Čítajte dokumentáciu platformy k dotknutému komponentu, nie všeobecného sprievodcu optimalizáciou batérie.
Spravované zariadenia pridávajú ďalšiu vrstvu. Zásada môže prepísať osobné nastavenie, takže zmena, ktorá vyzerá funkčne, sa vráti pri ďalšom obnovení zásad. Ak je požiadavka skutočná, použite organizáciou podporovaný proces výnimky a zapíšte, prečo výnimka existuje.
Čo zariadenie robí po prebudení
Automatické opätovné pripojenie nie je to isté ako blokovanie premávky počas medzery. Skontrolujte oboje: či sa tunel vráti a či aplikácia, ktorá sa počas medzery pokúsila odoslať, neodišla nechránená. Klient, ktorý sa znovu pripojí za dve sekundy, ale v prvej prepustí dotaz DNS, má pre pracovné zariadenie nesprávnu politiku zlyhania. Testujte neškodnými požiadavkami a cieľom, ktorý ovládate.
Obnova aplikácie je tretia otázka. Tunel, ktorý sa vráti, neopraví reláciu SSH, ktorej vypršal čas, a používatelia túto stratu relácie často hlásia ako zlyhanie VPN. Držte spolu v správe spúšťač, zostavenie klienta a presný čas, pretože táto kombinácia oddeľuje predvídateľný životný cyklus vypnutia obrazovky od servera, ktorý zlyháva nezávisle od zariadenia.