VPN pārtrūkst, kad ekrāns izslēdzas: kurš dzīves cikls?

Pārsūtīšana apstājas tajā brīdī, kad ekrāns satumst, un emblēma seko dažas sekundes vēlāk. Šo ainu rada trīs dažādas lietas: klienta process tiek ierobežots, ceļš kļūst neaktīvs un zaudē savu kartējumu, vai lietotne zaudē sesiju, ko tunelis nekad nepamanīja. Katram ir savi pierādījumi, un katrs labojums pieder citam slānim. Tālākā secība tos atšķir ar vienu kontrolētu testu, nevis visu iestatījumu pārbaudi.

Trīs bojājumi, kas izskatās vienādi

Ierobežots fona process pārstāj sūtīt keepalive, un pretējā puse galu galā pasludina tuneli mirušu. Neaktīvs kartējums ceļā var beigties, kamēr ierīce guļ, tāpēc atgriezeniskais trafiks nekad nesasniedz klientu, kurš joprojām ir pilnīgi dzīvs. Lietotne var zaudēt savienojumu, kamēr tunelis stāv, un tas rada kļūdas dialogu ar veselīgu VPN emblēmu aiz tā. No lietotāja skatpunkta visi trīs lasās kā VPN pārrāvums ekrāna izslēgšanas brīdī.

Atšķirība ir svarīga, jo risinājumi praksē ir pretrunā viens otram. Klienta atbrīvošana no enerģijas ierobežojumiem salabo pirmo gadījumu un neko nedara beigušam kartējumam. Keepalive pagarināšana salabo otro un tērē akumulatoru trešajā, kur sākotnēji nekas tīkla līmenī nebija nepareizi.

Salīdziniet aktīvo un neaktīvo stāvokli kontrolētos apstākļos

Turiet visu nemainīgu: tā pati ierīce, tas pats tīkls, tas pats galapunkts, tā pati lietotne. Bloķējiet ekrānu uz īsu fiksētu intervālu un pierakstiet trīs novērojumus: vai klients ziņo par atslēgšanos, vai jauns pieprasījums darbojas atbloķēšanas laikā un vai esošā pārsūtīšana atsākās. Pēc tam atkārtojiet ar darbojošos keepalive vai periodisku pieprasījumu un salīdziniet abas palaides. Viena mainīgā, kas mainīta starp divām palaidēm, ir vērtīgāka par nedēļu anekdotisku ziņojumu.

Laiks pieder pierakstam. Pārrāvums pēc deviņdesmit sekundēm smaržo pēc kartējuma vai keepalive intervāla, savukārt pārrāvums bloķēšanas brīdī norāda uz procesa apturēšanu. Pierakstiet gan izraisītāju, gan intervālu, jo nākamajam mēģinājumam vajag kaut ko, ar ko salīdzināt.

Izlasiet platformas fona politiku

Android ietvaros VPN pakalpojuma dzīves cikls ir platformas daļa, un always-on un block-without-VPN ir atsevišķi slēdži ar atsevišķu ietekmi. Klientu, kas nav always-on, var apturēt, kad sistēma atgūst resursus, un neviens lietotnes iestatījums to nemaina. iOS piemēro savus fona ierobežojumus tuneļa nodrošinātājam, un dokumentētā uzvedība atšķiras no darbvirsmas dēmona, kas vienkārši turpina darboties. Lasiet platformas dokumentāciju par attiecīgo komponentu, nevis vispārīgu akumulatora optimizācijas rokasgrāmatu.

Pārvaldītās ierīces pievieno vēl vienu slāni. Politika var ignorēt personīgo iestatījumu, tāpēc šķietami strādājoša izmaiņa atgriežas nākamajā politikas atjauninājumā. Ja prasība ir reāla, izmantojiet organizācijas atbalstīto izņēmuma procesu un pierakstiet, kāpēc izņēmums pastāv.

Ko ierīce dara pēc pamošanās

Automātiska atkārtota savienošana nav tas pats, kas trafika bloķēšana starplaikā. Pārbaudiet abus: vai tunelis atgriežas un vai lietotne, kas starplaikā mēģināja sūtīt, izgāja neaizsargāta. Klientam, kas atkārtoti savienojas divās sekundēs, bet pirmajā noplūdina DNS vaicājumu, darba ierīcei ir nepareiza kļūmes politika. Testējiet ar nekaitīgiem pieprasījumiem un galamērķi, kuru kontrolējat.

Lietotnes atjaunošana ir trešais jautājums. Atgriezies tunelis nesalabo SSH sesiju, kurai beidzies laiks, un lietotāji bieži ziņo par šo sesijas zudumu kā VPN kļūmi. Turiet kopā ziņojumā izraisītāju, klienta būvējumu un precīzo laiku, jo šī kombinācija atšķir paredzamu ekrāna izslēgšanas dzīves ciklu no servera, kas neizdodas neatkarīgi no ierīces.