VPN ĉesas kiam la ekrano malŝaltiĝas: kiu vivciklo?

La transigo haltas en la momento, kiam la ekrano malheliĝas, kaj la insigno sekvas kelkajn sekundojn poste. Tri malsamaj aferoj produktas tiun bildon: la klienta procezo estas limigita, la vojo senaktiviĝas kaj perdas sian mapigon, aŭ la aplikaĵo perdas seancon, kiun la tunelo neniam rimarkis. Ĉiu havas sian propran pruvon, kaj ĉiu ripeto apartenas al malsama tavolo. La sinsekvo malsupre apartigas ilin per unu kontrolita testo anstataŭ trarigardo de ĉiuj agordoj.

Tri fiaskoj, kiuj aspektas identaj

Limigita fona procezo ĉesas sendi keepalive-pakaĵojn, kaj la alia flanko finfine deklaras la tunelon morta. Senaktiva mapigo sur la vojo povas eksvalidiĝi dum la aparato dormas, do revena trafiko neniam atingas klienton, kiu ankoraŭ estas tute viva. Aplikaĵo povas perdi sian propran konekton dum la tunelo restas aktiva, kio produktas eraldialogon kun sana VPN-insigno malantaŭe. Laŭ la vidpunkto de la uzanto, ĉiuj tri legeblas kiel VPN, kiu falis ĉe ekrana malŝaltiĝo.

La distingo gravas, ĉar la rimedoj kontraŭdiras unu la alian en la praktiko. Escepti la klienton de energiaj limigoj riparas la unuan kazon kaj faras nenion por mapigo, kiu eksvalidiĝis. Etendi la keepalive-intervalojn riparas la duan kaj malŝparas baterion en la tria, kie nenio reta estis malĝusta komence.

Komparu aktivan kaj senaktivan sub kontrolo

Tenu ĉion konstanta: sama aparato, sama reto, sama finpunkto, sama aplikaĵo. Ŝlosu la ekranon dum mallonga fiksa intervalo kaj notu tri observojn: ĉu la kliento raportas malkonekton, ĉu nova peto funkcias ĉe malŝloso, kaj ĉu la ekzistanta transigo daŭriĝis. Poste ripetu kun keepalive aŭ perioda peto funkcianta kaj komparu la du rultempojn. Unu variablo ŝanĝita inter du rultempoj valoras pli ol semajno da anekdotaj raportoj.

Tempo apartenas al la protokolo. Falo post naŭdek sekundoj odoras kiel mapigo aŭ keepalive-intervalo, dum falo en la momento de ŝloso montras procezan paŭzigon. Notu kaj la kaŭzon kaj la intervalon, ĉar la sekva provo bezonas ion por kompari.

Legu la fonan politikon de la platformo

En Android la vivciklo de la VPN-servo estas parto de la platformo, kaj always-on kaj block-without-VPN estas apartaj ŝaltiloj kun apartaj efikoj. Kliento, kiu ne estas always-on, povas esti haltigita kiam la sistemo rekonkuras rimedojn, kaj neniu agordo en la aplikaĵo tion ŝanĝas. iOS aplikas siajn proprajn fonajn limigojn al la tunela provizanto, kaj la dokumentita konduto diferencas de labortabla demono, kiu simple daŭre funkcias. Legu la platforman dokumentaron por la koncerna komponanto anstataŭ ĝenerala gvidilo pri bateria optimumigo.

Administrataj aparatoj aldonas plian tavolon. Politiko povas superregi personan agordon, do ŝanĝo, kiu ŝajne funkcias, revenas ĉe la sekva politika refreŝigo. Uzu la subtenatan esceptan procezon de la organizo se la postulo estas vera, kaj notu, kial la escepto ekzistas.

Kion la aparato faras post vekiĝo

Aŭtomata rekonekto ne samas al blokado de trafiko dum la interspaco. Kontrolu ambaŭ: ĉu la tunelo revenas, kaj ĉu aplikaĵo, kiu provis sendi dum la interspaco, iris senprotekte. Kliento, kiu rekonektas en du sekundoj sed likas DNS-demandon en la unua, havas la malĝustan fiaskan politikon por laboraparto. Testu per sendanĝeraj petoj kaj celo, kiun vi kontrolas.

Aplikaĵa restarigo estas la tria demando. Tunelo, kiu revenas, ne riparas SSH-seancon, kiu tempolimis, kaj uzantoj ofte raportas tiun seancon perdon kiel la VPN-fiaskon. Tenu la kaŭzon, la klientan version kaj la precizan tempon kune en la raporto, ĉar tiu kombinaĵo apartigas antaŭvideblan ekran-malŝaltan vivciklon de servilo, kiu fiaskas sendepende de la aparato.