Bumabagsak ang VPN kapag naka-off ang screen: aling lifecycle?
Maaaring suspindihin ng naka-lock na screen ang client, hayaang ma-expire ang mapping, o patayin ang session ng app. Isang kontroladong pagsubok ang naghihiwalay sa mga ito bago baguhin ang anumang setting.
Humihinto ang paglilipat sa sandaling dumilim ang screen, at sumusunod ang badge pagkalipas ng ilang segundo. Tatlong magkaibang bagay ang gumagawa ng larawang iyon: nalilimitahan ang proseso ng client, nagiging idle ang landas at nawawala ang mapping nito, o nawawala ang session ng aplikasyon na hindi napansin ng tunnel. Bawat isa ay may sariling ebidensya, at bawat pag-aayos ay kabilang sa ibang layer. Hinihiwalay sila ng pagkakasunod-sunod sa ibaba gamit ang isang kontroladong pagsubok sa halip na suriin ang lahat ng setting.
Tatlong pagkabigo na magkamukha
Ang limitadong proseso sa background ay tumitigil sa pagpapadala ng keepalive, at sa huli ay idinedeklara ng kabilang dulo na patay ang tunnel. Maaaring ma-expire ang idle na mapping sa landas habang natutulog ang device, kaya hindi kailanman nakakarating ang return traffic sa client na buhay pa rin. Maaaring mawala ng aplikasyon ang sarili nitong koneksyon habang nakatayo ang tunnel, na gumagawa ng dialog ng error na may malusog na VPN badge sa likod. Sa pananaw ng user, ang tatlo ay binabasa bilang VPN na bumagsak nang naka-off ang screen.
Mahalaga ang pagkakaiba dahil nagkakasalungat ang mga lunas sa praktika. Ang pag-exempt sa client mula sa mga limitasyon sa enerhiya ay nag-aayos sa unang kaso at walang ginagawa para sa na-expire na mapping. Ang pagpapahaba ng keepalive ay nag-aayos sa pangalawa at nag-aaksaya ng baterya sa pangatlo, kung saan walang network-related na mali noong una.
Ihambing ang aktibo at idle sa ilalim ng kontrol
Panatilihing pare-pareho ang lahat: parehong device, parehong network, parehong endpoint, parehong aplikasyon. I-lock ang screen sa maikling fixed na interval at itala ang tatlong obserbasyon: kung nag-uulat ng disconnect ang client, kung gumagana ang bagong request sa pag-unlock, at kung nagpatuloy ang umiiral na paglilipat. Pagkatapos ay ulitin habang tumatakbo ang keepalive o pana-panahong request at ihambing ang dalawang run. Ang isang variable na binago sa pagitan ng dalawang run ay mas mahalaga kaysa isang linggong anecdotal na ulat.
Ang oras ay bahagi ng record. Ang pagbagsak pagkalipas ng siyamnapung segundo ay amoy mapping o keepalive interval, habang ang pagbagsak sa sandali ng lock ay tumuturo sa pagkasuspinde ng proseso. Itala ang trigger at ang interval, dahil kailangan ng susunod na pagsubok ng paghahambing.
Basahin ang patakaran sa background ng platform
Sa Android, ang lifecycle ng serbisyo ng VPN ay bahagi ng platform, at ang always-on at block-without-VPN ay magkahiwalay na switch na may magkahiwalay na epekto. Ang client na hindi always-on ay maaaring ihinto kapag binawi ng system ang mga resource, at walang setting sa app ang nagbabago nito. Naglalapat ang iOS ng sariling mga limitasyon sa background sa tunnel provider, at ang dokumentadong pag-uugali ay naiiba sa desktop daemon na tuloy lang sa pagtakbo. Basahin ang dokumentasyon ng platform para sa component na tinutukoy, hindi isang pangkalahatang gabay sa pag-optimize ng baterya.
Ang mga managed device ay nagdadagdag ng isa pang layer. Maaaring i-override ng patakaran ang personal na setting, kaya ang pagbabagong mukhang gumagana ay bumabalik sa susunod na refresh ng patakaran. Gamitin ang sinusuportahang proseso ng exception ng organisasyon kung totoo ang pangangailangan, at itala kung bakit may exception.
Ano ang ginagawa ng device pagkatapos magising
Ang awtomatikong muling pagkonekta ay hindi pareho sa pagharang ng traffic sa loob ng agwat. Suriin pareho: kung bumabalik ang tunnel, at kung ang aplikasyong nagtangkang magpadala sa agwat ay lumabas nang walang proteksyon. Ang client na muling kumokonekta sa loob ng dalawang segundo ngunit naglalabas ng DNS query sa una ay may maling patakaran sa pagkabigo para sa work device. Subukan gamit ang hindi mapaminsalang request at destinasyong kontrolado mo.
Ang pagbawi ng aplikasyon ang ikatlong tanong. Ang bumabalik na tunnel ay hindi nag-aayos ng SSH session na nag-time out, at madalas iulat ng mga user ang pagkawalang iyon ng session bilang pagkabigo ng VPN. Itago nang magkasama sa ulat ang trigger, build ng client at eksaktong oras, dahil ang kombinasyong iyon ang naghihiwalay ng predictable na screen-off lifecycle mula sa server na bumabagsak nang independiyente sa device.