VPN fell ut når skjermen blir slått av: kva livssyklus?

Overføringa stoppar i det augeblikket skjermen blir mørk, og merket kjem nokre sekund seinare. Tre ulike ting skaper det biletet: klientprosessen blir avgrensa, vegen går i dvale og mistar kartlegginga si, eller applikasjonen mistar ei økt som tunnelen aldri la merke til. Kvar har sine eigne prov, og kvar retting høyrer til eit anna lag. Rekkjefølgja nedanfor skil dei med éin kontrollert test i staden for ein gjennomgang av alle innstillingar.

Tre feil som ser like ut

Ein avgrensa bakgrunnsprosess sluttar å sende keepalives, og motparten erklærer til slutt tunnelen død. Ei inaktiv kartlegging på vegen kan gå ut medan eininga søv, slik at returtrafikk aldri når ein klient som framleis er heilt i live. Ein applikasjon kan miste si eiga tilkopling medan tunnelen står, noko som gir ein feildialog med eit sunt VPN-merke bak. Frå brukaren sin stol blir alle tre lesne som VPN som fall ut ved skjermslukking.

Skilnaden er viktig fordi tiltaka motseier kvarandre i praksis. Å unnta klienten frå straumbegrensingar rettar det første tilfellet og gjer ingenting for ei kartlegging som har gått ut. Å forlenge keepalives rettar det andre og sløser med batteriet i det tredje, der ingenting nettverksrelatert var gale i utgangspunktet.

Samanlikn aktiv og inaktiv under kontroll

Hald alt konstant: same eining, same nettverk, same endepunkt, same applikasjon. Lås skjermen i eit kort fast intervall og noter tre observasjonar: om klienten rapporterer ein fråkopling, om ein ny førespurnad verkar ved opplåsing, og om den eksisterande overføringa heldt fram. Gjenta deretter med ein keepalive eller ein periodisk førespurnad som køyrer, og samanlikn dei to køyringane. Éin variabel endra mellom to køyringar er verdt meir enn ei veke med anekdotiske rapportar.

Tidspunktet høyrer i protokollen. Eit fall etter nitti sekund luktar av ei kartlegging eller eit keepalive-intervall, medan eit fall i låseaugneblinken peikar på prosessuspensjon. Skriv ned både utløysaren og intervallet, fordi neste forsøk treng noko å samanlikne med.

Les bakgrunnspolicyen til plattformen

På Android er livssyklusen til VPN-tenesta ein del av plattformen, og always-on og block-without-VPN er separate brytarar med separate effektar. Ein klient som ikkje er always-on, kan bli stoppa når systemet tek tilbake ressursar, og inga innstilling i appen endrar det. iOS legg sine eigne bakgrunnsgrenser på tunelleverandøren, og den dokumenterte åtferda skil seg frå ein skrivebordsdaemon som berre held fram med å køyre. Les plattformdokumentasjonen for komponenten det gjeld, ikkje ein generell rettleiar for batterioptimalisering.

Administrerte einingar legg til eit nytt lag. Ein policy kan overstyre ei personleg innstilling, så ei endring som ser ut til å verke, rullar tilbake ved neste policyoppdatering. Bruk den støtta unntaksprosessen til organisasjonen om kravet er reelt, og skriv ned kvifor unntaket finst.

Kva eininga gjer etter oppvakning

Automatisk attilkopling er ikkje det same som å blokkere trafikk i gapet. Kontroller begge: om tunnelen kjem tilbake, og om ein applikasjon som prøvde å sende i gapet, gjekk ut ubeskytta. Ein klient som koplar til igjen på to sekund, men lek ein DNS-førespurnad i det første, har feil feilpolicy for ei arbeidseining. Test med ufarlege førespurnader og eit mål du kontrollerer.

Applikasjonsattvinning er det tredje spørsmålet. Ein tunnel som kjem tilbake, reparerer ikkje ei SSH-økt som tima ut, og brukarar rapporterer ofte det økttapet som VPN-feilen. Hald utløysaren, klientbyggen og det nøyaktige tidspunktet saman i rapporten, fordi den kombinasjonen skil ein føreseieleg skjermslukkingslivssyklus frå ein tenar som feilar uavhengig av eininga.