Разделеният тунел все още изключва приложение, което сте деинсталирали

Старото приложение го няма, а списъкът на разделения тунел все още има запис за него. Нищо видимо не се чупи и точно затова записът остава там с месеци. После някой инсталира друга програма в същата папка или управляван профил възстановява правилото при всяко повторно свързване и трафикът започва да поема път, който никой не е планирал. Изключването надживя причината за съществуването си.

Почистването тук е главно въпрос на идентичност: към какво сочи правилото сега и кой притежава списъка.

Симптомът: изключване, което не съвпада с нищо

Остарелият запис е невидим при нормална употреба. Става видим по три начина: приложение, което сте очаквали да минава през тунела, излиза директно; нова програма наследява старо изключение; или клиентът отказва да запази промяна, защото управляваният профил я презаписва. И трите изглеждат като отделни бъгове, а и трите са един и същ проблем с отчетността. Всяко от тях е евтино за проверка и скъпо за погрешна диагноза.

Започнете, като прочетете правилото, а не като го изтриете.

Разберете какво идентифицира правилото

Реализациите на разделен тунел обвързват изключванията с различни неща: път до изпълним файл, име на пакет, идентификатор на пакет или маршрут. Правило, базирано на път, сочи към файл, който може вече да не съществува или сега да е друг файл. Правило, базирано на пакет, сочи към идентичност, която нова инсталация може да използва повторно. Прочетете документацията на клиента за полето, което разглеждате, защото едно и също текстово поле означава различни неща в различните продукти. Ръководството за VpnService на Android е ориентирът за случая с пакети.

Показваното име е най-ненадеждната част от записа и точно нея хората четат.

Правилата за път и правилата за пакет се държат различно

Правило за път, което оцелява след деинсталация, обикновено става неактивно, а неактивно е добрият изход. Лошият изход е път, който се използва повторно, защото новият изпълним файл тихо наследява изключването. Правилата за пакет се държат отново различно: продуктът може да игнорира недостъпен пакет, да го отхвърли или да продължи да съвпада по име, когато нещо ново заеме това име.

Не пренасяйте предположение от един клиент към друг. Проверете какво всъщност прави вашият клиент с липсваща цел, най-добре като създадете условието нарочно на тестова машина и наблюдавате кой процес наследява изключването.

Премахнете го чрез собственика

Ако списъкът идва от управляван профил, локалното редактиране е временна промяна, която ще бъде възстановена при следващото свързване. Променете профила или помолете този, който го притежава, и потвърдете, че промяната оцелява след повторно свързване. Ако списъкът е локален, премахнете записа и проверете дали клиентът е пренаписал конфигурацията си, вместо да пази старата в паметта.

Празният списък не е целта. Целта е списък, чиито записи все още отговарят на реални изисквания.

След това тествайте и двете посоки

След почистването тествайте приложение, което трябва да остане изключено, и приложение, което вече трябва да минава през тунела. Проверете поведението на DNS отделно, защото политиката на резолвера е различен контрол от списъка с изключвания. След това се свържете отново веднъж и тествайте пак, защото възстановеният профил е най-честият начин едно почистване тихо да отмени само себе си.

Дръжте описание в един ред до всяко останало изключване. Този ред е това, което пречи на списъка да се превърне в музей, и превръща следващото почистване в петминутна задача.