VPN pade, ko se zaslon ugasne: kateri življenjski cikel?
Zaklenjen zaslon lahko začasno ustavi odjemalca, pusti preslikavo, da poteče, ali ubije sejo aplikacije. En nadzorovan test jih loči pred vsako spremembo nastavitev.
Prenos se ustavi v trenutku, ko se zaslon potemni, in značka sledi nekaj sekund pozneje. Tri različne stvari ustvarjajo to sliko: odjemalčev proces se omeji, pot preide v mirovanje in izgubi svojo preslikavo, ali aplikacija izgubi sejo, ki je tunel ni nikoli opazil. Vsaka ima svoje dokaze in vsak popravek sodi v drugo plast. Vrstni red spodaj jih loči z enim nadzorovanim testom namesto pregleda vseh nastavitev.
Tri okvare, ki izgledajo enako
Omejen proces v ozadju preneha pošiljati keepalive in druga stran na koncu razglasi tunel za mrtev. Nedejavna preslikava na poti lahko poteče, medtem ko naprava spi, zato povratni promet nikoli ne doseže odjemalca, ki je še povsem živ. Aplikacija lahko izgubi lastno povezavo, medtem ko tunel stoji, kar ustvari pogovorno okno z napako in zdravo značko VPN za njim. Z vidika uporabnika se vse tri berejo kot VPN, ki je padel ob izklopu zaslona.
Razlika je pomembna, ker si ukrepi v praksi nasprotujejo. Izvzetje odjemalca iz energetskih omejitev popravi prvi primer in ne naredi ničesar za poteklo preslikavo. Podaljšanje keepalive popravi drugega in zapravi baterijo v tretjem, kjer od začetka ni bilo nič omrežnega narobe.
Primerjajte dejavno in nedejavno stanje pod nadzorom
Vse držite nespremenjeno: ista naprava, isto omrežje, ista končna točka, ista aplikacija. Zaklenite zaslon za kratek fiksni interval in zapišite tri ugotovitve: ali odjemalec poroča o prekinitvi, ali nova zahteva deluje ob odklepu in ali se je obstoječi prenos nadaljeval. Nato ponovite z delujočim keepalive ali redno zahtevo in primerjajte oba zagona. Ena spremenjena spremenljivka med dvema zagonoma je vredna več kot teden anekdotičnih poročil.
Čas sodi v zapis. Padec po devetdesetih sekundah diši po preslikavi ali intervalu keepalive, medtem ko padec v trenutku zaklepa kaže na zaustavitev procesa. Zapišite tako sprožilec kot interval, ker naslednji poskus potrebuje nekaj za primerjavo.
Preberite politiko ozadja platforme
V Androidu je življenjski cikel storitve VPN del platforme, always-on in block-without-VPN pa sta ločeni stikali z ločenimi učinki. Odjemalec, ki ni always-on, se lahko ustavi, ko sistem prevzame vire, in nobena nastavitev v aplikaciji tega ne spremeni. iOS na ponudnika tunela uporablja svoje omejitve v ozadju in dokumentirano vedenje se razlikuje od namiznega demona, ki preprosto teče naprej. Preberite dokumentacijo platforme za zadevno komponento, ne splošnega vodnika za optimizacijo baterije.
Upravljane naprave dodajo še eno plast. Pravilnik lahko preglasi osebno nastavitev, zato se sprememba, ki deluje, ob naslednji osvežitvi pravilnika povrne. Če je zahteva resnična, uporabite podprti postopek izjeme organizacije in zapišite, zakaj izjema obstaja.
Kaj naprava naredi po prebujanju
Samodejno ponovno povezovanje ni isto kot blokiranje prometa med vrzeljo. Preverite oboje: ali se tunel vrne in ali je aplikacija, ki je med vrzeljo poskušala pošiljati, šla ven nezaščitena. Odjemalec, ki se znova poveže v dveh sekundah, a v prvi izpusti poizvedbo DNS, ima napačno politiko napak za delovno napravo. Preizkusite z neškodljivimi zahtevami in ciljem, ki ga nadzorujete.
Obnovitev aplikacije je tretje vprašanje. Tunel, ki se vrne, ne popravi seje SSH, ki je potekla, in uporabniki to izgubo seje pogosto prijavijo kot okvaro VPN. V poročilu hranite skupaj sprožilec, različico odjemalca in točen čas, ker ta kombinacija loči predvidljiv življenjski cikel izklopa zaslona od strežnika, ki odpove neodvisno od naprave.