Opdelt tunnel udelukker stadig en app, du har afinstalleret

Den gamle app er væk, og listen over opdelte tunneler har stadig en post til den. Intet går synligt i stykker, og derfor bliver den liggende i månedsvis. Så installerer nogen et andet program i den samme mappe, eller en administreret profil gendanner reglen ved hver genopkobling, og trafikken begynder at tage en vej, som ingen havde planlagt. Undtagelsen overlevede grunden til, at den fandtes.

Oprydningen handler mest om identitet: hvad reglen peger på nu, og hvem der ejer listen.

Symptomet: en undtagelse, der ikke matcher noget

En forældet post er usynlig i normal brug. Den bliver synlig på tre måder: en app, du forventede gik gennem tunnelen, går direkte, et nyt program arver en gammel undtagelse, eller klienten nægter at gemme en ændring, fordi den administrerede profil overskriver den. Alle tre ser ud som separate fejl, og alle tre er det samme bogholderiproblem. Hver af dem er billig at kontrollere og dyr at fejldiagnosticere.

Begynd med at læse reglen, ikke med at slette den.

Find ud af, hvad reglen identificerer

Implementeringer af opdelt tunnel baserer undtagelser på forskellige ting: en sti til en eksekverbar fil, et pakkenavn, en bundle-identifikator eller en rute. En stibaseret regel peger på en fil, der måske ikke findes længere, eller som nu kan være en anden fil. En pakkebaseret regel peger på en identitet, som en ny installation kan genbruge. Læs klientens dokumentation for det felt, du kigger på, fordi det samme tekstfelt betyder forskellige ting i forskellige produkter. Androids VpnService-vejledning er reference for det pakkebaserede tilfælde.

Det viste navn er den mindst pålidelige del af posten, og det er den del, folk læser.

Stiregler og pakkeregler opfører sig forskelligt

En stiregel, der overlever en afinstallation, bliver normalt inaktiv, og inaktiv er det gode resultat. Det dårlige resultat er en sti, der genbruges, fordi den nye eksekverbare fil lydløst arver undtagelsen. Pakkeregler opfører sig igen anderledes: et produkt kan ignorere en utilgængelig pakke, afvise den eller fortsætte med at matche på navn, når noget nyt tager det navn.

Overfør ikke en antagelse fra én klient til en anden. Kontroller, hvad din faktisk gør med et manglende mål, ideelt ved at skabe tilstanden bevidst på en testmaskine og se, hvilken proces der arver undtagelsen.

Fjern den via ejeren

Hvis listen kommer fra en administreret profil, er en lokal redigering en midlertidig ændring, der gendannes ved næste genopkobling. Ændr profilen, eller spørg den, der ejer den, og bekræft, at ændringen overlever en genopkobling. Hvis listen er lokal, fjern posten, og kontroller, at klienten har skrevet sin konfiguration om i stedet for at beholde den gamle i hukommelsen.

En tom liste er ikke målet. Målet er en liste, hvis poster stadig svarer til reelle krav.

Test begge retninger bagefter

Efter oprydningen skal du teste en app, der stadig bør være udelukket, og en app, der nu bør gå gennem tunnelen. Bekræft DNS-adfærd separat, fordi resolverpolitik er en anden kontrol end undtagelseslisten. Genopkobl derefter én gang, og test igen, da en gendannet profil er den mest almindelige måde, hvorpå en oprydning stille fortryder sig selv.

Hold et formål på én linje ved siden af hver tilbageværende undtagelse. Den linje er det, der forhindrer listen i at blive et museum, og den gør den næste oprydning til en fem-minutters opgave.