Omfanget av VPN-tilbakestilling på Android: kva kvart lag faktisk slettar

Android har fire separate handlingar som folk kallar ei VPN-tilbakestilling, og dei slettar ulike ting. Tømming av bufferen til ein app fjernar mellombelse filer; tømming av lagringa fjernar sjølve profilen. Ei nettverksnullstilling byggjer sambandsstakken på nytt, og ei fabrikknullstilling byter ut brukardatapartisjonen. Vel handlinga ut frå tilstanden du mistenkjer, ikkje av vane. Gissar du feil, er profilen eller registreringsvegen du trong borte før du har diagnostisert noko.

Her er regelen eg nyttar ved kvar førespurnad: nemn tilstanden, nemn eigaren, og fjern deretter berre kopien til den eigaren. Resten av denne sida handlar om kva Android-komponent som held kva byte.

Kvar ein Android-VPN-profil faktisk bur

Ein tredjepartsklient på ein ikkje-administrert telefon held profilen i si eiga appdatamappe, som ei innstillingsfil, ein JSON-blob eller ei lita SQLite-database. Det er denne mappa punktet Tøm lagring i Innstillingar slettar. Profilen står ikkje i VPN-lista til systemet: den lista held sambandsposten klienten registrerte via VpnService, og omfattar sambandsnamnet, eigarpakken og eit kvar som helst alltid-på-flagg brukaren har sett.

VpnService er røyrarbeid, ikkje lagring. Klienten ber om samtykke éin gong, byggjer eit tun-grensesnitt og flyttar pakkane sjølv, så plattformen treng aldri å forstå profilformatet. Difor blir ei konfigurasjonsfil kopiert frå ein annan telefon ofte importert som ein tom profil eller fell valideringa.

Legitimasjon følgjer ein annan veg. Ein nøkkel eller eit sertifikat henta via KeyChain til systemet blir verande i eit systemstyrt lager, så sletting av appdata kan la legitimasjonen vere brukbar og berre fjerna klienten sitt alias til han.

Administrerte einingar legg til ein andre eigar. Ein arbeidsprofil oppretta av ein EMM køyrer sin eigen kopi av klienten under sin eigen policy, og ein alltid-på-VPN kan festast av einingapolicy slik at brukaren ikkje kan kopie han frå. På slike einingar blir profilen vanlegvis levert ved registrering i staden for skriven inn for hand. Gjenoppretting er då eit val om nyregistrering, ikkje om nyimport.

Buffer, lagring, nettverksnullstilling, fabrikknullstilling

Dei fire handlingane svarar til desse grensene. Les rada for tilstanden du mistenkjer før du trykkjer på noko.

Bufring er det tryggaste og det minst nyttige. Det fjernar mellombelse filer, som òg er der ein klient kan ha lagt loggen ein støttemedarbeidar nettopp bad deg om. Feilsøkingsrettleiinga til Android for appar handsamar buffer og lagring som to ulike slettingar, og det bør du òg gjere.

Tøm lagring er den eigentlege nullstillinga per app. Ho fjernar profilen, den lagra gatewayen og tillitsflagga klienten heldt for bestemte nettverk. Ho kallar ikkje tilbake KeyChain-postar, fjernar ikkje ein system-VPN-post som ein annan app eig, og på ein administrert profil fjernar ho ikkje policyen som opphavleg sende profilen.

Nettverksnullstillinga i Innstillingar gjeld heile eininga, og det nøyaktige omfanget endrar seg med produsent og Android-versjon. Stadfestingsdialogen på din versjon er den einaste pålitelege fråsegna om kva han vil gløyme.

Skriv ned vegen tilbake først

Før eit kvar som helst destruktivt steg, skriv ned fem ting: klientversjon, profilnamn, gatewayadresse, tenesteeigar og det nøyaktige steget der sambandet sviktar.

Desse fem fakta skil ein klientfeil frå ein policy- eller serverfeil. Eit tidsavbrot, ei sertifikatavvising og ei umiddelbar avvising er tre ulike feil, og kvar peikar på ein ulik eigar. Tømmer du lagringa først, misser du klientbevisa som ville ha skilt dei. Ta vare på ein reinsa kopi av loggen medan han enno finst.

Stadfest deretter korleis sambandet ville bli gjenskapt. Eit visingsnamn og eit vertsnamn er ikkje nok når profilen hang saman med eit klientcertifikat, ein administrert konfigurasjon eller ei MFA-registrering bunden til denne eininga.

Bootstrap-låsen ingen planlegg

Éin feilmodus fortener sin eigen seksjon. Om den einaste staden å laste ned profilen er ein intern portal som berre er nåbar gjennom tunnelen du er i ferd med å fjerna, skapar tømming av lagringa ein blindveg utan veg ut i appen.

Alltid-på-VPN med blokker tilkoplingar utan VPN gjer det til eit totalt utfall: telefonen har ingen fungerande veg til portalen, og klienten har ingen profil til å reise tunnelen. Dei to tilstandane held kvarandre på plass.

Vegen ut er prosedyremessig, ikkje teknisk. Eksporter eller fotografer konfigurasjonen medan tunnelen enno verkar, stadfest at portalen har ei rute som ikkje er avhengig av VPN-en, og tøm først noko etterpå. På ei administrert eining, spør administratoren kva gjenopprettingsveg som finst før du rører profilen.

Stadfest den gjenoppbygde tunnelen

Når profilen er tilbake, test i rekkjefølgje: namneoppslag, ein TCP-samband til ein kjend intern vert og den feilblokkerande åtferda du faktisk er avhengig av. Rekkjefølgja har noko å seie fordi ein tunnel kan kome opp og likevel leke DNS.

Eit nøkkelikon i statuslinja beviser at grensesnittet finst, ikkje meir.

Om sambandet framleis sviktar etter ei målretta nullstilling, slutt å auke storleiken på handlinga. Ta vare på bevisa før og etter, noter kva lag du tømte, og overlat saka til komponenteigaren med dei fem fakta. Ei fabrikknullstilling er eit eige val med mykje høgare kostnad, og det er ikkje neste steg på ei VPN-sjekkliste.