VPN katkeaa, kun näyttö sammuu: mikä elinkaari?

Siirto pysähtyy heti, kun näyttö tummuu, ja merkki seuraa muutamaa sekuntia myöhemmin. Kolme eri asiaa tuottaa tämän kuvan: asiakasprosessia rajoitetaan, polku jää jouten ja menettää mappauksensa, tai sovellus menettää istunnon, jota tunneli ei koskaan huomannut. Jokaisella on omat todisteensa, ja jokainen korjaus kuuluu eri kerrokseen. Alla oleva järjestys erottaa ne yhdellä kontrolloidulla testillä sen sijaan, että kaikki asetukset käytäisiin läpi.

Kolme vikaa, jotka näyttävät samoilta

Rajoitettu taustaprosessi lakkaa lähettämästä keepaliveja, ja vastapuoli julistaa tunnelin lopulta kuolleeksi. Polun jouten oleva mappaus voi vanhentua laitteen nukkuessa, joten paluuliikenne ei koskaan saavuta asiakasta, joka on vielä täysin elossa. Sovellus voi menettää oman yhteytensä tunnelin pysyessä pystyssä, mikä tuottaa virhedialogin, jonka takana on terve VPN-merkki. Käyttäjän näkökulmasta kaikki kolme luetaan VPN:n katkeamisena näytön sammuessa.

Ero on tärkeä, koska keinot ovat käytännössä ristiriidassa. Asiakkaan vapauttaminen energiarajoituksista korjaa ensimmäisen tapauksen eikä tee mitään vanhentuneelle mappaukselle. Keepalivejen pidentäminen korjaa toisen ja tuhlaa akkua kolmannessa, jossa mikään verkkoon liittyvä ei ollut alun perin väärin.

Vertaa aktiivista ja joutilasta kontrolloidusti

Pidä kaikki vakiona: sama laite, sama verkko, sama päätepiste, sama sovellus. Lukitse näyttö lyhyeksi kiinteäksi ajaksi ja kirjaa kolme havaintoa: ilmoittaako asiakas katkeamisesta, toimiiko uusi pyyntö lukituksen avauksessa ja jatkuiko olemassa oleva siirto. Toista sitten keepaliven tai säännöllisen pyynnön kanssa ja vertaa kahta ajoa. Yksi muuttuja kahden ajon välillä on enemmän arvoinen kuin viikko anekdoottisia raportteja.

Ajoitus kuuluu pöytäkirjaan. Yhdeksänkymmenen sekunnin jälkeen tapahtuva katkeaminen haiskahtaa mappaukselta tai keepalive-väliltä, kun taas lukitsemisen hetkellä tapahtuva katkeaminen viittaa prosessin keskeytykseen. Kirjaa sekä laukaisin että väli, koska seuraava yritys tarvitsee jotain vertailukohdaksi.

Lue alustan taustakäytäntö

Androidissa VPN-palvelun elinkaari on osa alustaa, ja always-on ja block-without-VPN ovat erillisiä kytkimiä, joilla on erilliset vaikutukset. Asiakas, joka ei ole always-on, voidaan pysäyttää, kun järjestelmä ottaa resursseja takaisin, eikä mikään sovelluksen asetus muuta sitä. iOS soveltaa omia taustarajoituksiaan tunnelin tarjoajaan, ja dokumentoitu käyttäytyminen eroaa työpöytädaemonista, joka yksinkertaisesti jatkaa toimintaansa. Lue alustan dokumentaatio kyseisestä komponentista, älä yleistä akun optimointiohjetta.

Hallitut laitteet lisäävät yhden kerroksen. Käytäntö voi ohittaa henkilökohtaisen asetuksen, joten toimivalta näyttävä muutos palautuu seuraavassa käytännön päivityksessä. Käytä organisaation tukemaa poikkeusprosessia, jos vaatimus on todellinen, ja kirjaa, miksi poikkeus on olemassa.

Mitä laite tekee heräämisen jälkeen

Automaattinen uudelleenyhdistäminen ei ole sama kuin liikenteen estäminen aukon aikana. Tarkista molemmat: palaako tunneli ja lähtikö sovellus, joka yritti lähettää aukon aikana, ulos suojaamattomana. Asiakas, joka yhdistää uudelleen kahdessa sekunnissa mutta vuotaa DNS-kyselyn ensimmäisessä, on työlaitteelle väärällä vikakäytännöllä. Testaa vaarattomilla pyynnöillä ja kohteella, jota hallitset.

Sovelluksen palautuminen on kolmas kysymys. Palaava tunneli ei korjaa SSH-istuntoa, jonka aika loppui, ja käyttäjät raportoivat usein tämän istunnon menetyksen VPN-vikana. Pidä laukaisin, asiakasversio ja tarkka ajoitus yhdessä raportissa, koska tuo yhdistelmä erottaa ennustettavan näytön sammumisen elinkaaren palvelimesta, joka epäonnistuu laitteesta riippumatta.