Omfanget af VPN-nulstilling på Android: hvad hvert lag faktisk sletter

Android har fire separate handlinger, som folk kalder en VPN-nulstilling, og de sletter forskellige ting. Rydning af en apps cache fjerner midlertidige filer; rydning af dens lager fjerner selve profilen. En netværksnulstilling genopbygger forbindelsesstakken, og en fabriksnulstilling erstatter brugerdatapartitionen. Vælg handlingen ud fra den tilstand, du mistænker, ikke af vane. Hvis du gætter forkert, er profilen eller tilmeldingsvejen, du havde brug for, væk, før du har diagnosticeret noget.

Her er reglen, jeg bruger ved hvert opkald: navngiv tilstanden, navngiv dens ejer, og fjern derefter kun den ejers kopi. Resten af denne side handler om, hvilken Android-komponent der holder hvilke bytes.

Hvor en VPN-profil på Android faktisk bor

En tredjepartsklient på en ikke-administreret telefon holder sin profil i sin egen app-datamappe, som en indstillingsfil, en JSON-blob eller en lille SQLite-database. Det er den mappe, punktet Ryd lager i Indstillinger sletter. Profilen er ikke på systemets VPN-liste: den liste indeholder forbindelsesposten, som klienten registrerede via VpnService, og den omfatter forbindelsens navn, den ejende pakke og ethvert always-on-flag, brugeren har sat.

VpnService er VVS-arbejde, ikke lager. Klienten beder om samtykke én gang, bygger et tun-interface og flytter selv pakkerne, så platformen behøver aldrig at forstå profilformatet. Derfor importeres en konfigurationsfil kopieret fra en anden telefon ofte som en tom profil eller fejler valideringen.

Loginoplysninger følger en anden vej. En nøgle eller et certifikat, der er hentet via systemets KeyChain, bliver i et systemstyret lager, så sletning af appdata kan efterlade oplysningerne brugbare og kun fjerne klientens alias til dem.

Administrerede enheder tilføjer en anden ejer. En arbejdsprofil oprettet af en EMM kører sin egen kopi af klienten under sin egen politik, og en always-on VPN kan fastgøres af enhedspolitik, så brugeren ikke kan afbryde den. På sådanne enheder bliver profilen normalt leveret ved tilmelding i stedet for skrevet ind manuelt. Gendannelse er så en beslutning om ny tilmelding, ikke om ny import.

Cache, lager, netværksnulstilling, fabriksnulstilling

De fire handlinger svarer til disse grænser. Læs rækken for den tilstand, du mistænker, før du trykker på noget.

Rydning af cache er det sikreste og det mindst nyttige. Det fjerner midlertidige filer, som også er der, hvor en klient kan have lagt den log, en supportmedarbejder lige har bedt om. Androids fejlfindingsvejledning for apps behandler cache og lager som to forskellige sletninger, og det bør du også gøre.

Ryd lager er den egentlige nulstilling pr. app. Det fjerner profilen, den gemte gateway og de tillidsflag, klienten har holdt for bestemte netværk. Det tilbagekalder ikke KeyChain-poster, fjerner ikke en system-VPN-post, som en anden app ejer, og på en administreret profil fjerner det ikke den politik, der oprindeligt skubbede profilen ud.

Netværksnulstillingen i Indstillinger gælder hele enheden, og dens præcise omfang ændrer sig med producent og Android-version. Bekræftelsesdialogen på din build er den eneste pålidelige erklæring om, hvad den vil glemme.

Skriv vejen tilbage ned først

Før ethvert destruktivt skridt skal du skrive fem ting ned: klientversion, profilnavn, gateway-adresse, tjenesteejer og det præcise trin, hvor forbindelsen fejler.

De fem fakta er det, der adskiller en klientfejl fra en politik- eller serverfejl. En timeout, en certifikatafvisning og en øjeblikkelig afvisning er tre forskellige fejl, og hver peger på en forskellig ejer. Rydder du lager først, mister du klientbeviset, som ville have skelnet dem. Gem en renset kopi af loggen, mens den stadig findes.

Bekræft derefter, hvordan forbindelsen ville blive genskabt. Et visningsnavn og et værtsnavn er ikke nok, når profilen afhang af et klientcertifikat, en administreret konfiguration eller en MFA-tilmelding bundet til denne enhed.

Den bootstrap-låsning, ingen planlægger

En fejltilstand fortjener sit eget afsnit. Hvis det eneste sted at downloade profilen er en intern portal, der kun kan nås gennem den tunnel, du er ved at fjerne, skaber sletning af lageret en blindgyde uden vej ud i appen.

Always-on VPN med bloker forbindelser uden VPN gør det til et totalt udfald: telefonen har ingen fungerende vej til portalen, og klienten har ingen profil til at rejse tunnelen. De to tilstande holder hinanden på plads.

Vejen ud er proceduremæssig, ikke teknisk. Eksportér eller fotografer konfigurationen, mens tunnelen stadig virker, bekræft at portalen har en rute, der ikke afhænger af VPN'en, og ryd først derefter noget. På en administreret enhed skal du spørge administratoren, hvilken gendannelsesvej der findes, før du rører profilen.

Verificér den genopbyggede tunnel

Når profilen er tilbage, test i rækkefølge: navneopløsning, en TCP-forbindelse til en kendt intern vært og den fejlblokerende adfærd, du faktisk regner med. Rækkefølgen er vigtig, fordi en tunnel kan komme op og stadig lække DNS.

Et nøgleikon i statuslinjen beviser, at interfacet findes, ikke mere.

Hvis forbindelsen stadig fejler efter en målrettet nulstilling, så stop med at øge handlingens størrelse. Gem beviset før og efter, notér hvilket lag du ryddede, og giv sagen videre til komponentejeren med de fem fakta. En fabriksnulstilling er en separat beslutning med en meget højere pris, og den er ikke det næste skridt på en VPN-tjekliste.