VPN pada kad se ekran ugasi: koji životni ciklus?
Zaključan ekran može obustaviti klijenta, pustiti mapiranje da istekne ili ubiti sesiju aplikacije. Jedan kontrolisani test ih razdvaja prije bilo kakve promjene postavki.
Prenos se zaustavlja u trenutku kad ekran potamni, a značka slijedi nekoliko sekundi kasnije. Tri različite stvari stvaraju tu sliku: klijentski proces biva ograničen, put ostane bez prometa i izgubi mapiranje, ili aplikacija izgubi sesiju koju tunel nikad nije primijetio. Svaka ima svoj dokaz, i svaka popravka pripada drugom sloju. Redoslijed ispod ih razdvaja jednim kontrolisanim testom umjesto pregleda svih postavki.
Tri kvara koja izgledaju identično
Ograničeni pozadinski proces prestaje slati keepalive, a drugi kraj na kraju proglasi tunel mrtvim. Neaktivno mapiranje na putu može isteći dok uređaj spava, pa povratni promet nikad ne stigne do klijenta koji je još potpuno živ. Aplikacija može izgubiti vlastitu vezu dok tunel ostaje podignut, što daje dijalog greške sa zdravom VPN značkom iza njega. Iz korisničke perspektive sva tri se čitaju kao VPN koji je pao pri gašenju ekrana.
Razlika je važna jer se rješenja u praksi međusobno proturječe. Izuzeće klijenta od energetskih ograničenja popravlja prvi slučaj i ne radi ništa za mapiranje koje je isteklo. Produženje keepalive-a popravlja drugi i troši bateriju u trećem, gdje ništa mrežno nije bilo pogrešno od početka.
Uporedite aktivno i mirovanje pod kontrolom
Držite sve konstantnim: isti uređaj, ista mreža, ista krajnja tačka, ista aplikacija. Zaključajte ekran na kratak fiksni interval i zabilježite tri zapažanja: da li klijent prijavljuje prekid, da li novi zahtjev radi pri otključavanju i da li se postojeći prenos nastavio. Zatim ponovite s uključenim keepalive-om ili periodičnim zahtjevom i uporedite dva prolaza. Jedna promijenjena varijabla između dva prolaza vrijedi više od sedmice anegdotskih izvještaja.
Vrijeme pripada u zapis. Pad nakon devedeset sekundi miriše na mapiranje ili interval keepalive-a, dok pad u trenutku zaključavanja ukazuje na obustavu procesa. Zapišite i okidač i interval, jer sljedeći pokušaj treba nešto s čime će se uporediti.
Pročitajte pozadinsku politiku platforme
Na Androidu je životni ciklus VPN usluge dio platforme, a always-on i block-without-VPN su odvojene sklopke s odvojenim efektima. Klijent koji nije always-on može biti zaustavljen kad sistem povrati resurse, i nijedna postavka u aplikaciji to ne mijenja. iOS primjenjuje vlastita pozadinska ograničenja na pružaoca tunela, a dokumentovano ponašanje razlikuje se od desktop demona koji jednostavno nastavlja raditi. Čitajte dokumentaciju platforme za dotičnu komponentu, a ne opći vodič za optimizaciju baterije.
Upravljani uređaji dodaju još jedan sloj. Politika može nadjačati ličnu postavku, pa se promjena koja izgleda da radi vraća pri sljedećem osvježavanju politike. Koristite proces izuzetka koji organizacija podržava ako je zahtjev stvaran, i zapišite zašto izuzetak postoji.
Šta uređaj radi nakon buđenja
Automatsko ponovno povezivanje nije isto kao blokiranje prometa tokom praznine. Provjerite oboje: da li se tunel vraća i da li je aplikacija koja je pokušala poslati tokom praznine izašla nezaštićena. Klijent koji se ponovo poveže za dvije sekunde, a u prvoj propusti DNS upit, ima pogrešnu politiku otkaza za radni uređaj. Testirajte bezopasnim zahtjevima i odredištem koje kontrolišete.
Oporavak aplikacije je treće pitanje. Tunel koji se vrati ne popravlja SSH sesiju koja je istekla, a korisnici često prijavljuju taj gubitak sesije kao kvar VPN-a. Držite okidač, verziju klijenta i tačno vrijeme zajedno u izvještaju, jer ta kombinacija razdvaja predvidljiv životni ciklus gašenja ekrana od servera koji pada nezavisno od uređaja.