VPN katkeb, kui ekraan lülitub välja: milline elutsükkel?

Ülekanne peatub hetkel, mil ekraan tumeneb, ja märk järgneb paar sekundit hiljem. Seda pilti tekitavad kolm erinevat asja: kliendi protsessi piiratakse, tee jääb tühjaks ja kaotab oma vastenduse, või rakendus kaotab sessiooni, mida tunnel kunagi ei märganud. Igal on oma tõendid ja iga parandus kuulub eri kihti. Alljärgnev järjekord eristab neid ühe kontrollitud katsega, mitte kõigi sätete läbivaatamisega.

Kolm tõrget, mis näevad identsed välja

Piiratud taustaprotsess lõpetab hoiuste saatmise ja teine pool kuulutab lõpuks tunneli surnuks. Aegunud vastendus teel võib seadme magamise ajal aeguda, nii et tagasitulev liiklus ei jõua kunagi kliendini, kes on veel täiesti elus. Rakendus võib kaotada oma ühenduse, samal ajal kui tunnel püsib püsti, mis annab veadialoogi, mille taga on terve VPN-i märk. Kasutaja vaatevinklist loetakse kõiki kolme kui VPN-i, mis ekraani väljalülitamisel katkes.

Erinevus on oluline, sest ravivõtted on praktikas vastuolus. Kliendi vabastamine energiatõhususe piirangutest parandab esimese juhtumi ega tee aegunud vastenduse jaoks midagi. Hoiuste pikendamine parandab teise ja raiskab akut kolmandas, kus polnud algusest peale midagi võrguga seotud valesti.

Võrrelge aktiivset ja tühja olekut kontrollitud tingimustes

Hoidke kõik muutumatuna: sama seade, sama võrk, sama otspunkt, sama rakendus. Lukustage ekraan lühikeseks fikseeritud intervalliks ja kirjutage üles kolm tähelepanekut: kas klient teatab katkestusest, kas uus päring töötab lukust avamisel ja kas olemasolev ülekanne jätkus. Seejärel korrake hoiuse või perioodilise päringuga ja võrrelge kahte jooksu. Üks muutuja, mis kahe jooksu vahel muutus, on väärt rohkem kui nädal anekdootlikke aruandeid.

Ajastus kuulub protokolli. Üheksakümne sekundi järel toimuv kukkumine lõhnab vastenduse või hoiuse intervalli järele, samas kui lukustamise hetkel toimuv kukkumine viitab protsessi peatamisele. Kirjutage üles nii päästik kui ka intervall, sest järgmine katse vajab midagi, millega võrrelda.

Lugege platvormi taustapoliitikat

Androidis on VPN-teenuse elutsükkel platvormi osa ning always-on ja block-without-VPN on eraldi lülitid eraldi mõjudega. Klienti, mis ei ole always-on, saab peatada, kui süsteem ressursse tagasi võtab, ja ükski rakendusesisene säte ei muuda seda. iOS rakendab tunnelipakkujale oma taustapiirangud ja dokumenteeritud käitumine erineb töölaua deemonist, mis lihtsalt jätkab töötamist. Lugege kõnealuse komponendi platvormidokumentatsiooni, mitte üldist aku optimeerimise juhendit.

Hallatavad seadmed lisavad veel ühe kihi. Poliitika võib isikliku sätte üle kirjutada, nii et toimivana näiv muudatus võetakse järgmisel poliitika värskendamisel tagasi. Kui nõue on tõeline, kasutage organisatsiooni toetatud erandiprotsessi ja kirjutage üles, miks erand olemas on.

Mida seade pärast ärkamist teeb

Automaatne taasühendamine ei ole sama mis liikluse blokeerimine vahe ajal. Kontrollige mõlemat: kas tunnel naaseb ja kas rakendus, mis vahe ajal saatmist proovis, läks välja kaitsmata. Klient, mis ühendub kahe sekundiga uuesti, aga lekib esimesel sekundil DNS-päringu, on tööseadme jaoks vale tõrkepoliitikaga. Katsetage kahjutute päringutega ja sihtkohaga, mida kontrollite.

Rakenduse taastamine on kolmas küsimus. Naasev tunnel ei paranda SSH-sessiooni, mille aeg lõppes, ja kasutajad teatavad sellest sessiooni kaotusest sageli kui VPN-i tõrkest. Hoidke päästik, kliendi versioon ja täpne aeg aruandes koos, sest see kombinatsioon eristab etteaimatavat ekraani väljalülitamise elutsüklit serverist, mis ebaõnnestub seadmest sõltumatult.