Den gamle appen er borte, og listen over splittet tunnel har fortsatt en oppføring for den. Ingenting går synlig i stykker, og derfor blir den liggende i månedsvis. Så installerer noen et annet program i samme mappe, eller en administrert profil gjenoppretter regelen ved hver gjentilkobling, og trafikken begynner å ta en vei ingen hadde planlagt. Unntaket overlevde grunnen til at det fantes.

Oppryddingen handler mest om identitet: hva regelen peker på nå, og hvem som eier listen.

Symptomet: et unntak som ikke passer til noe

En utdatert oppføring er usynlig i normal bruk. Den blir synlig på tre måter: en app du forventet gikk gjennom tunnelen går direkte, et nytt program arver et gammelt unntak, eller klienten nekter å lagre en endring fordi den administrerte profilen overskriver den. Alle tre ser ut som separate feil, og alle tre er det samme regnskapsproblemet. Hver av dem er billig å sjekke og dyr å feildiagnostisere.

Begynn med å lese regelen, ikke med å slette den.

Finn ut hva regelen identifiserer

Implementasjoner av splittet tunnel knytter unntak til forskjellige ting: en bane til en kjørbar fil, et pakkenavn, en pakkeidentifikator eller en rute. En banebasert regel peker på en fil som kanskje ikke finnes lenger, eller som nå kan være en annen fil. En pakkebasert regel peker på en identitet som en ny installasjon kan gjenbruke. Les klientens dokumentasjon for feltet du ser på, fordi samme tekstfelt betyr forskjellige ting i ulike produkter. Androids VpnService-veiledning er referansen for det pakkebaserte tilfellet.

Det viste navnet er den minst pålitelige delen av oppføringen, og det er den delen folk leser.

Baneregler og pakkeregler oppfører seg forskjellig

En baneregel som overlever en avinstallering blir vanligvis inaktiv, og inaktiv er det gode resultatet. Det dårlige resultatet er en bane som gjenbrukes, fordi den nye kjørbare filen lydløst arver unntaket. Pakkeregler oppfører seg igjen annerledes: et produkt kan ignorere en utilgjengelig pakke, avvise den eller fortsette å matche på navn når noe nytt tar det navnet.

Ikke overfør en antakelse fra én klient til en annen. Sjekk hva din faktisk gjør med et manglende mål, ideelt ved å skape tilstanden bevisst på en testmaskin og se hvilken prosess som arver unntaket.

Fjern den via eieren

Hvis listen kommer fra en administrert profil, er lokal redigering en midlertidig endring som gjenopprettes ved neste gjentilkobling. Endre profilen, eller spør den som eier den, og bekreft at endringen overlever en gjentilkobling. Hvis listen er lokal, fjern oppføringen og sjekk at klienten skrev konfigurasjonen sin på nytt i stedet for å beholde den gamle i minnet.

En tom liste er ikke målet. Målet er en liste der oppføringene fortsatt samsvarer med reelle krav.

Test begge retninger etterpå

Etter oppryddingen, test en app som fortsatt bør være utelukket og en app som nå bør gå gjennom tunnelen. Bekreft DNS-atferd separat, fordi resolverpolicy er en annen kontroll enn unntakslisten. Koble deretter til på nytt én gang og test igjen, siden en gjenopprettet profil er den vanligste måten en opprydding stille angrer seg selv på.

Hold et formål på én linje ved siden av hvert gjenværende unntak. Den linjen er det som hindrer listen i å bli et museum, og den gjør neste opprydding til en fem minutters jobb.

Relaterte artikler