Omfanget av VPN-tilbakestilling på Android: hva hvert lag faktisk sletter

Android har fire separate handlinger som folk kaller en VPN-tilbakestilling, og de sletter forskjellige ting. Tømming av en apps buffer fjerner midlertidige filer; tømming av lagringen fjerner selve profilen. En nettverksnullstilling bygger forbindelsesstakken på nytt, og en fabrikknullstilling erstatter brukerdatapartisjonen. Velg handlingen ut fra tilstanden du mistenker, ikke av vane. Gjetter du feil, er profilen eller registreringsveien du trengte borte før du har diagnostisert noe.

Her er regelen jeg bruker ved hver henvendelse: navngi tilstanden, navngi eieren, og fjern deretter bare den eierens kopi. Resten av denne siden handler om hvilken Android-komponent som holder hvilke byte.

Hvor en Android-VPN-profil faktisk bor

En tredjepartsklient på en ikke-administrert telefon holder profilen i sin egen appdatamappe, som en innstillingsfil, en JSON-blob eller en liten SQLite-database. Det er denne mappen punktet Tøm lagring i Innstillinger sletter. Profilen står ikke i systemets VPN-liste: den listen holder forbindelsesposten klienten registrerte via VpnService, og omfatter forbindelsesnavnet, den eierpakken og ethvert alltid-på-flagg brukeren har satt.

VpnService er rørarbeid, ikke lagring. Klienten ber om samtykke én gang, bygger et tun-grensesnitt og flytter pakkene selv, så plattformen trenger aldri å forstå profilformatet. Derfor blir en konfigurasjonsfil kopiert fra en annen telefon ofte importert som en tom profil eller feiler valideringen.

Legitimasjon følger en annen vei. En nøkkel eller et sertifikat hentet via systemets KeyChain blir i et systemstyrt lager, så sletting av appdata kan la legitimasjonen være brukbar og bare fjerne klientens alias til den.

Administrerte enheter legger til en andre eier. En arbeidsprofil opprettet av en EMM kjører sin egen kopi av klienten under sin egen policy, og en alltid-på-VPN kan festes av enhetspolicy slik at brukeren ikke kan koble den fra. På slike enheter blir profilen vanligvis levert ved registrering i stedet for skrevet inn for hånd. Gjenoppretting er da et valg om nyregistrering, ikke om nyimport.

Buffer, lagring, nettverksnullstilling, fabrikknullstilling

De fire handlingene svarer til disse grensene. Les raden for tilstanden du mistenker før du trykker på noe.

Bufring er det sikreste og det minst nyttige. Det fjerner midlertidige filer, som også er der en klient kan ha lagt loggen en supportmedarbeider nettopp ba deg om. Androids feilsøkingsveiledning for apper behandler buffer og lagring som to forskjellige slettinger, og det bør du også gjøre.

Tøm lagring er den egentlige nullstillingen per app. Den fjerner profilen, den lagrede gatewayen og tillitsflaggene klienten holdt for bestemte nettverk. Den tilbakekaller ikke KeyChain-poster, fjerner ikke en system-VPN-post som en annen app eier, og på en administrert profil fjerner den ikke policyen som opprinnelig sendte profilen.

Nettverksnullstillingen i Innstillinger gjelder hele enheten, og dens nøyaktige omfang endres med produsent og Android-versjon. Bekreftelsesdialogen på din versjon er den eneste pålitelige erklæringen om hva den vil glemme.

Skriv ned veien tilbake først

Før ethvert destruktivt trinn, skriv ned fem ting: klientversjon, profilnavn, gatewayadresse, tjenesteeier og det nøyaktige trinnet der forbindelsen feiler.

Disse fem fakta skiller en klientfeil fra en policy- eller serverfeil. En tidsavbrudd, en sertifikatavvisning og en umiddelbar avvisning er tre ulike feil, og hver peker på en ulik eier. Tømmer du lagringen først, mister du klientbevisene som ville ha skilt dem. Ta vare på en renset kopi av loggen mens den fortsatt finnes.

Bekreft deretter hvordan forbindelsen ville blitt gjenskapt. Et visningsnavn og et vertsnavn er ikke nok når profilen avhang av et klientcertifikat, en administrert konfigurasjon eller en MFA-registrering bundet til denne enheten.

Bootstrap-låsen ingen planlegger

Én feilmodus fortjener sin egen seksjon. Hvis det eneste stedet å laste ned profilen er en intern portal som bare nås gjennom tunnelen du er i ferd med å fjerne, skaper tømming av lagringen en blindvei uten vei ut i appen.

Alltid-på-VPN med blokker tilkoblinger uten VPN gjør det til et totalt utfall: telefonen har ingen fungerende vei til portalen, og klienten har ingen profil til å reise tunnelen. De to tilstandene holder hverandre på plass.

Veien ut er prosedyremessig, ikke teknisk. Eksporter eller fotografer konfigurasjonen mens tunnelen fortsatt virker, bekreft at portalen har en rute som ikke avhenger av VPN-en, og tøm først noe etterpå. På en administrert enhet, spør administratoren hvilken gjenopprettingsvei som finnes før du rører profilen.

Verifiser den gjenoppbygde tunnelen

Når profilen er tilbake, test i rekkefølge: navneoppslag, en TCP-forbindelse til en kjent intern vert og den feilblokkerende atferden du faktisk er avhengig av. Rekkefølgen betyr noe fordi en tunnel kan komme opp og likevel lekke DNS.

Et nøkkelikon i statuslinjen beviser at grensesnittet finnes, ikke mer.

Hvis forbindelsen fortsatt feiler etter en målrettet nullstilling, slutt å øke størrelsen på handlingen. Ta vare på bevisene før og etter, noter hvilket lag du tømte, og overlat saken til komponenteieren med de fem fakta. En fabrikknullstilling er et eget valg med mye høyere kostnad, og det er ikke neste trinn på en VPN-sjekkliste.