Split-tunnel sluit nog steeds een app uit die je hebt verwijderd

De oude app is weg, en de split-tunnellijst bevat er nog steeds een item voor. Niets breekt zichtbaar, en daarom blijft het maandenlang staan. Dan installeert iemand een ander programma in dezelfde map, of een beheerd profiel herstelt de regel bij elke herverbinding, en het verkeer begint een pad te nemen dat niemand had gepland. De uitsluiting overleefde de reden waarom hij bestond.

Dit opruimen gaat vooral over identiteit: waar de regel nu naar verwijst, en wie de lijst bezit.

Het symptoom: een uitsluiting die nergens bij past

Een verouderd item is onzichtbaar in normaal gebruik. Het wordt op drie manieren zichtbaar: een app waarvan je verwachtte dat hij via de tunnel ging, gaat rechtstreeks, een nieuw programma erft een oude uitzondering, of de client weigert een wijziging op te slaan omdat het beheerde profiel die overschrijft. Alle drie lijken afzonderlijke bugs, en alle drie zijn hetzelfde boekhoudprobleem. Elk is goedkoop te controleren en duur om verkeerd te diagnosticeren.

Begin met de regel te lezen, niet met hem te verwijderen.

Ontdek wat de regel identificeert

Implementaties van split-tunneling baseren uitsluitingen op verschillende dingen: een pad naar een uitvoerbaar bestand, een pakketnaam, een pakket-id of een route. Een op pad gebaseerde regel verwijst naar een bestand dat misschien niet meer bestaat, of dat nu een ander bestand kan zijn. Een op pakket gebaseerde regel verwijst naar een identiteit die een nieuwe installatie opnieuw kan gebruiken. Lees de documentatie van de client voor het veld dat je bekijkt, want hetzelfde tekstvak betekent bij verschillende producten iets anders. Androids VpnService-handleiding is de referentie voor het op pakketten gebaseerde geval.

De getoonde naam is het minst betrouwbare deel van het item, en juist dat deel lezen mensen.

Padregels en pakketregels gedragen zich anders

Een padregel die een verwijdering overleeft, wordt meestal inactief, en inactief is de goede uitkomst. De slechte uitkomst is een pad dat opnieuw wordt gebruikt, omdat het nieuwe uitvoerbare bestand de uitzondering stil erft. Pakketregels gedragen zich weer anders: een product kan een niet-beschikbaar pakket negeren, het afwijzen of op naam blijven matchen wanneer iets nieuws die naam opeist.

Neem geen aanname over van de ene client naar de andere. Controleer wat de jouwe werkelijk doet met een ontbrekend doel, ideaal door de toestand bewust op een testmachine te creëren en te kijken welk proces de uitzondering erft.

Verwijder hem via de eigenaar

Als de lijst uit een beheerd profiel komt, is lokaal bewerken een tijdelijke wijziging die bij de volgende herverbinding wordt hersteld. Wijzig het profiel, of vraag degene die het bezit, en bevestig dat de wijziging een herverbinding overleeft. Als de lijst lokaal is, verwijder dan het item en controleer of de client zijn configuratie opnieuw heeft geschreven in plaats van de oude in het geheugen te houden.

Een lege lijst is niet het doel. Het doel is een lijst waarvan de items nog steeds aan echte eisen voldoen.

Test daarna beide richtingen

Test na het opruimen een app die nog steeds uitgesloten zou moeten zijn en een app die nu via de tunnel zou moeten gaan. Bevestig het DNS-gedrag apart, want het resolverbeleid is een andere controle dan de uitsluitingslijst. Verbind daarna één keer opnieuw en test opnieuw, want een hersteld profiel is de meest voorkomende manier waarop een opruiming zichzelf stilletjes ongedaan maakt.

Houd naast elke resterende uitzondering een doel van één regel bij. Die regel is wat voorkomt dat de lijst een museum wordt, en maakt de volgende opruiming een klus van vijf minuten.