Omfattningen av en VPN-återställning på Android: vad varje lager faktiskt rensar

Android har fyra separata åtgärder som folk kallar en VPN-återställning, och de rensar olika saker. Att rensa en apps cache tar bort temporära filer; att rensa dess lagring tar bort själva profilen. En nätverksåterställning bygger om anslutningsstacken, och en fabriksåterställning ersätter användardatapartitionen. Välj åtgärd efter tillståndet du misstänker, inte av vana. Gissar du fel är profilen eller registreringsvägen du behövde borta innan du diagnostiserat något.

Här är regeln jag använder vid varje ärende: namnge tillståndet, namnge dess ägare och ta sedan bort bara den ägarens kopia. Resten av sidan handlar om vilken Android-komponent som håller vilka byte.

Var en Android-VPN-profil faktiskt bor

En tredjepartsklient på en icke-hanterad telefon håller profilen i sin egen appdatamapp, som en inställningsfil, en JSON-blob eller en liten SQLite-databas. Det är den mappen som posten Rensa lagring i Inställningar tar bort. Profilen finns inte i systemets VPN-lista: den listan håller anslutningsposten som klienten registrerade via VpnService, och omfattar anslutningsnamnet, ägarpaketet och eventuell alltid-på-flagga som användaren satt.

VpnService är rörarbete, inte lagring. Klienten ber om samtycke en gång, bygger ett tun-gränssnitt och flyttar paketen själv, så plattformen behöver aldrig förstå profilformatet. Därför importeras en konfigurationsfil kopierad från en annan telefon ofta som en tom profil eller klarar inte valideringen.

Inloggningsuppgifter följer en annan väg. En nyckel eller ett certifikat som hämtats via systemets KeyChain stannar i ett systemhanterat lager, så att ta bort appdata kan lämna uppgifterna användbara och bara ta bort klientens alias till dem.

Hanterade enheter lägger till en andra ägare. En arbetsprofil som skapas av en EMM kör sin egen kopia av klienten under sin egen policy, och en alltid-på-VPN kan fästas av enhetspolicy så att användaren inte kan koppla från den. På sådana enheter tillhandahålls profilen vanligtvis vid registreringen i stället för att skrivas in för hand. Återställning är då ett beslut om nyregistrering, inte om nyimport.

Cache, lagring, nätverksåterställning, fabriksåterställning

De fyra åtgärderna motsvarar dessa gränser. Läs raden för tillståndet du misstänker innan du rör något.

Cache-rensning är det säkraste och det minst användbara. Det tar bort temporära filer, vilket också är där en klient kan ha lagt loggen som en supportmedarbetare just bad dig om. Androids felsökningsguide för appar behandlar cache och lagring som två olika borttagningar, och det bör du också göra.

Rensa lagring är den egentliga återställningen per app. Det tar bort profilen, den sparade gatewayen och de förtroendeflaggor som klienten höll för vissa nätverk. Det återkallar inte KeyChain-poster, tar inte bort en system-VPN-post som en annan app äger, och på en hanterad profil tar det inte bort policyn som ursprungligen skickade ut profilen.

Nätverksåterställningen i Inställningar gäller hela enheten, och dess exakta omfattning ändras med tillverkare och Android-version. Bekräftelsedialogen i din build är det enda tillförlitliga beskedet om vad den kommer att glömma.

Skriv ner vägen tillbaka först

Skriv ner fem saker före varje destruktivt steg: klientversion, profilnamn, gatewayadress, tjänstens ägare och det exakta steg där anslutningen misslyckas.

Det är dessa fem fakta som skiljer ett klientfel från ett policy- eller serverfel. En timeout, en certifikatavvisning och ett omedelbart avslag är tre olika fel, och varje fel pekar på en annan ägare. Rensar du lagringen först förlorar du bevisningen på klientsidan som skulle ha skilt dem. Behåll en rensad kopia av loggen medan den fortfarande finns.

Bekräfta sedan hur anslutningen skulle återskapas. Ett visningsnamn och ett värdnamn räcker inte när profilen berodde på ett klientcertifikat, en hanterad konfiguration eller en MFA-registrering bunden till den här enheten.

Bootstrap-låset som ingen planerar

Ett felläge förtjänar ett eget avsnitt. Om den enda platsen att hämta profilen från är en intern portal som bara nås genom tunneln du är på väg att ta bort, skapar rensning av lagringen en återvändsgränd utan väg ut i appen.

Alltid-på-VPN med alternativet blockera anslutningar utan VPN gör det till ett totalt avbrott: telefonen har ingen fungerande väg till portalen, och klienten har ingen profil att resa tunneln med. De två tillstånden håller varandra på plats.

Vägen ut är procedurell, inte teknisk. Exportera eller fotografera konfigurationen medan tunneln fortfarande fungerar, bekräfta att portalen har en rutt som inte beror på VPN:en, och rensa först därefter något. På en hanterad enhet, fråga administratören vilken återställningsväg som finns innan du rör profilen.

Verifiera den återuppbyggda tunneln

När profilen är tillbaka, testa i ordning: namnuppslagning, en TCP-anslutning till en känd intern värd och det felblockerande beteende du faktiskt förlitar dig på. Ordningen spelar roll eftersom en tunnel kan komma upp och ändå läcka DNS.

En nyckelikon i statusfältet bevisar att gränssnittet finns, inget mer.

Om anslutningen fortfarande misslyckas efter en riktad återställning, sluta öka åtgärdens storlek. Behåll bevisningen före och efter, notera vilket lager du rensade, och lämna ärendet till komponentägaren med de fem fakta. En fabriksåterställning är ett separat beslut med mycket högre kostnad, och det är inte nästa steg i en VPN-checklista.