VPN nutrūksta išjungus ekraną: kuris gyvavimo ciklas?

Perdavimas sustoja tą akimirką, kai ekranas patamsėja, o ženklelis atsiranda po kelių sekundžių. Šį vaizdą sukuria trys skirtingi dalykai: kliento procesas apribojamas, kelias tampa neaktyvus ir praranda savo mapping įrašą, arba programa praranda sesiją, kurios tunelis niekada nepastebėjo. Kiekvienas turi savo įrodymus, ir kiekvienas taisymas priklauso kitam sluoksniui. Toliau pateikta tvarka atskiria juos vienu kontroliuojamu testu, o ne visų nustatymų peržiūra.

Trys gedimai, kurie atrodo vienodai

Apribotas foninis procesas nustoja siųsti keepalive, ir kita pusė galiausiai paskelbia tunelį mirusiu. Neaktyvus mapping įrašas kelyje gali pasibaigti, kol įrenginys miega, todėl grįžtantis srautas niekada nepasiekia kliento, kuris dar visiškai gyvas. Programa gali prarasti savo ryšį, kol tunelis stovi, o tai sukuria klaidos dialogą su sveiku VPN ženkleliu už jo. Vartotojo požiūriu visi trys skaitomi kaip VPN nutrūkimas išjungus ekraną.

Skirtumas svarbus, nes sprendimai praktiškai prieštarauja vienas kitam. Kliento atleidimas nuo energijos apribojimų sutaiso pirmąjį atvejį ir nieko nepadaro pasibaigusiam mapping įrašui. Keepalive pratęsimas sutaiso antrąjį ir eikvoja bateriją trečiajame, kur iš pradžių nieko tinklo nebuvo neteisinga.

Palyginkite aktyvų ir neaktyvų režimą kontroliuojamomis sąlygomis

Laikykite viską pastovu: tas pats įrenginys, tas pats tinklas, tas pats galinis taškas, ta pati programa. Užrakinkite ekraną trumpam fiksuotam intervalui ir užrašykite tris stebėjimus: ar klientas praneša apie atsijungimą, ar nauja užklausa veikia atrakinus, ir ar esamas perdavimas buvo atnaujintas. Tada pakartokite su veikiančiu keepalive ar periodine užklausa ir palyginkite du paleidimus. Vienas pakeistas kintamasis tarp dviejų paleidimų vertas daugiau nei savaitė anekdotinių ataskaitų.

Laikas priklauso įrašui. Nutrūkimas po devyniasdešimt sekundžių primena mapping įrašą ar keepalive intervalą, o nutrūkimas užrakinimo momentu rodo proceso sustabdymą. Užrašykite ir suveikimo priežastį, ir intervalą, nes kitam bandymui reikia su kuo palyginti.

Perskaitykite platformos foninę politiką

Android sistemoje VPN paslaugos gyvavimo ciklas yra platformos dalis, o always-on ir block-without-VPN yra atskiri jungikliai su atskiru poveikiu. Klientas, kuris nėra always-on, gali būti sustabdytas, kai sistema susigrąžina išteklius, ir joks programos nustatymas to nepakeičia. iOS taiko savo foninius apribojimus tunelio teikėjui, o dokumentuotas elgesys skiriasi nuo darbalaukio demono, kuris tiesiog toliau veikia. Skaitykite platformos dokumentaciją apie atitinkamą komponentą, o ne bendrą baterijos optimizavimo vadovą.

Tvarkomi įrenginiai prideda dar vieną sluoksnį. Politika gali nepaisyti asmeninio nustatymo, todėl veikiančiu atrodantis pakeitimas grįžta per kitą politikos atnaujinimą. Jei reikalavimas tikras, naudokite organizacijos palaikomą išimties procesą ir užrašykite, kodėl išimtis egzistuoja.

Ką įrenginys daro po pabudimo

Automatinis prisijungimas iš naujo nėra tas pats, kas srauto blokavimas per spragą. Patikrinkite abu: ar tunelis grįžta, ir ar programa, kuri bandė siųsti per spragą, išėjo neapsaugota. Klientas, kuris prisijungia iš naujo per dvi sekundes, bet pirmąją praleidžia DNS užklausą, turi netinkamą gedimo politiką darbo įrenginiui. Testuokite nekenksmingomis užklausomis ir jūsų kontroliuojamu tikslu.

Programos atkūrimas yra trečias klausimas. Grįžtantis tunelis nesutaiso pasibaigusios SSH sesijos, ir vartotojai dažnai praneša apie tą sesijos praradimą kaip VPN gedimą. Laikykite kartu ataskaitoje suveikimo priežastį, kliento versiją ir tikslų laiką, nes ši kombinacija atskiria nuspėjamą ekrano išjungimo ciklą nuo serverio, kuris nepavyksta nepriklausomai nuo įrenginio.