Omvang van Android-VPN-resets: wat elke laag werklik uitvee

Android het vier afsonderlike bewerkings wat mense 'n VPN-reset noem, en hulle verwyder verskillende dinge. Om 'n app se kasgeheue skoon te maak, verwyder tydelike lêers; om sy berging skoon te maak, verwyder die profiel self. 'n Netwerk-reset bou die verbindingstapel weer op, en 'n fabrieksreset vervang die gebruikersdatapartisie. Kies die bewerking op grond van die toestand wat jy vermoed, nie uit gewoonte nie. As jy verkeerd raai, is die profiel of die inskrywingsroete wat jy nodig gehad het weg voordat jy enigiets gediagnoseer het.

Hier is die reël wat ek by elke oproep gebruik: noem die toestand, noem sy eienaar, en verwyder dan net daardie eienaar se kopie. Die res van hierdie bladsy handel oor watter Android-komponent watter grepe hou.

Waar 'n Android-VPN-profiel werklik woon

'n Derdeparty-kliënt op 'n onbestuurde foon hou sy profiel in sy eie app-data-gids, as 'n voorkeurlêer, 'n JSON-blok of 'n klein SQLite-databasis. Dit is die gids wat die Instellings-inskrywing Vee berging uitvee. Die profiel is nie in die stelsel se VPN-lys nie: daardie lys hou die verbindingsrekord wat die kliënt via VpnService geregistreer het, wat die verbindingsnaam, die pakket wat dit besit, en enige altyd-aan-vlag wat die gebruiker gestel het, insluit.

VpnService is loodgieterswerk, nie berging nie. Die kliënt vra een keer toestemming, bou 'n tun-koppelvlak en skuif self pakkette, so die platform hoef nooit die profielformaat te verstaan nie. Dit is waarom 'n konfigurasielêer wat van 'n ander foon gekopieer is dikwels as 'n leë profiel ingevoer word of die validering misluk.

Bewyse volg 'n ander pad. 'n Sleutel of sertifikaat wat deur die stelsel se KeyChain verkry is, bly in 'n stelselbestuurde stoor, so die uitvee van app-data kan die bewys bruikbaar laat terwyl slegs die kliënt se alias daarvoor verwyder word.

Bestuurde toestelle voeg 'n tweede eienaar by. 'n Werksprofiel wat deur 'n EMM geskep is, hardloop sy eie kopie van die kliënt onder sy eie beleid, en 'n altyd-aan-VPN kan deur toestelbeleid vasgepen word sodat die gebruiker dit nie kan ontkoppel nie. Op daardie toestelle word die profiel gewoonlik tydens inskrywing voorsien eerder as om met die hand ingetik te word. Herstel is dan 'n herinskrywingsbesluit, nie 'n herinvoer een nie.

Kas, berging, netwerk-reset, fabrieksreset

Die vier bewerkings val binne hierdie grense. Lees die ry vir die toestand wat jy vermoed voordat jy enigiets tik.

Om kas skoon te maak is die veiligste en die minste nuttige. Dit verwyder tydelike lêers, wat ook die plek is waar 'n kliënt dalk die log gelos het wat 'n ondersteuningsagent nou net by jou gevra het. Android se gids vir app-probleemoplossing behandel kas en berging as twee verskillende uitveë, en jy behoort ook so te maak.

Vee berging is die regte per-app-reset. Dit verwyder die profiel, die gestoorde gateway en die vertrouensvlae wat die kliënt vir bepaalde netwerke gehou het. Dit herroep nie KeyChain-inskrywings nie, verwyder nie 'n stelsel-VPN-rekord wat aan 'n ander app behoort nie, en op 'n bestuurde profiel verwyder dit nie die beleid wat die profiel oorspronklik gestoot het nie.

Die netwerk-reset in Instellings is toestelwyd, en die presiese omvang daarvan verander met vervaardiger en Android-weergawe. Die bevestigingsdialoog op jou bou is die enigste betroubare verklaring van wat dit sal vergeet.

Teken eers die terugpad aan

Voor enige vernietigende stap, skryf vyf dinge neer: kliëntweergawe, profielnaam, gateway-adres, dienseienaar, en die presiese stadium waar die verbinding misluk.

Daardie vyf feite is wat 'n kliëntfout van 'n beleids- of bedienerfout skei. 'n Tydverstreke, 'n sertifikaatverwerping en 'n onmiddellike weiering is drie verskillende mislukkings, en elkeen wys na 'n ander eienaar. Vee eers berging en jy verloor die kliëntkant-bewyse wat hulle sou kon onderskei. Hou 'n gesuiwerde kopie van die log terwyl dit nog bestaan.

Bevestig dan hoe die verbinding herskep sou word. 'n Vertoonnaam en 'n hostnaam is nie genoeg wanneer die profiel afhanklik was van 'n kliëntsertifikaat, 'n bestuurde konfigurasie of 'n MFA-inskrywing wat aan hierdie toestel gebind is nie.

Die bootstrap-uitsluiting waarvoor niemand beplan nie

Een mislukkingsmodus verdien sy eie afdeling. As die enigste plek om die profiel af te laai 'n interne portaal is wat deur die tonnel bereikbaar is wat jy op die punt is om te verwyder, skep die uitvee van berging 'n doodloopstraat sonder enige uitweg in die app.

Altyd-aan-VPN met blokkeer verbindings sonder VPN maak dit 'n volledige onderbreking: die foon het geen werkende pad na die portaal nie, en die kliënt het geen profiel om die tonnel op te bring nie. Die twee toestande hou mekaar in plek.

Die uitweg is prosedureel, nie tegnies nie. Voer die konfigurasie uit of fotografeer dit terwyl die tonnel nog werk, bevestig dat die portaal 'n roete het wat nie van die VPN afhanklik is nie, en vee eers daarna iets uit. Op 'n bestuurde toestel, vra die administrateur watter herstelpad bestaan voordat jy aan die profiel raak.

Verifieer die herboude tonnel

Nadat die profiel terug is, toets in volgorde: naamresolusie, 'n TCP-verbinding na 'n bekende interne host, en die mislukkingblokkeringsgedrag waarop jy werklik staatmaak. Die volgorde maak saak, want 'n tonnel kan opkom en steeds DNS lek.

'n Sleutelikoon in die statusbalk bewys die koppelvlak bestaan, niks meer nie.

As die verbinding steeds misluk ná 'n gerigte reset, hou op om die omvang van die bewerking op te skaal. Hou die voor- en na-bewyse, noteer watter laag jy skoongemaak het, en gee die saak aan die komponenteienaar oor met daardie vyf feite van vroeër. 'n Fabrieksreset is 'n aparte besluit met 'n veel hoër koste, en dit is nie die volgende stap in 'n VPN-kontrolelys nie.