Tunel dzielony nadal wyklucza aplikację, którą odinstalowałeś

Stara aplikacja zniknęła, a lista tunelu dzielonego nadal zawiera jej wpis. Nic widocznie się nie psuje, dlatego wpis zostaje tam miesiącami. Potem ktoś instaluje inny program w tym samym folderze albo profil zarządzany przywraca regułę przy każdym ponownym połączeniu, i ruch zaczyna podążać ścieżką, której nikt nie zaplanował. Wykluczenie przeżyło powód, dla którego istniało.

Porządkowanie tego to głównie kwestia tożsamości: na co reguła teraz wskazuje i kto jest właścicielem listy.

Objaw: wykluczenie, które do niczego nie pasuje

Nieaktualny wpis jest niewidoczny w normalnym użyciu. Staje się widoczny na trzy sposoby: aplikacja, która miała iść przez tunel, idzie bezpośrednio, nowy program dziedziczy stare wykluczenie albo klient odmawia zapisania zmiany, bo profil zarządzany ją nadpisuje. Wszystkie trzy wyglądają jak osobne błędy, a wszystkie trzy to ten sam problem z ewidencją. Każdy jest tani do sprawdzenia i drogi w przypadku błędnej diagnozy.

Zacznij od przeczytania reguły, a nie od jej usunięcia.

Ustal, co identyfikuje reguła

Implementacje tunelu dzielonego opierają wykluczenia na różnych rzeczach: ścieżce pliku wykonywalnego, nazwie pakietu, identyfikatorze pakietu albo trasie. Reguła oparta na ścieżce wskazuje plik, który może już nie istnieć albo może być teraz innym plikiem. Reguła oparta na pakiecie wskazuje tożsamość, którą nowa instalacja może ponownie wykorzystać. Przeczytaj dokumentację klienta dla pola, na które patrzysz, bo to samo pole tekstowe znaczy różne rzeczy w różnych produktach. Przewodnik po VpnService w Androidzie jest punktem odniesienia dla przypadku opartego na pakiecie.

Wyświetlana nazwa to najmniej wiarygodna część wpisu i właśnie ją ludzie czytają.

Reguły ścieżek i reguły pakietów zachowują się różnie

Reguła ścieżki, która przetrwa odinstalowanie, zwykle staje się nieaktywna, a nieaktywność to dobry wynik. Zły wynik to ścieżka, która jest ponownie używana, bo nowy plik wykonywalny po cichu dziedziczy wykluczenie. Reguły pakietów zachowują się znowu inaczej: produkt może ignorować niedostępny pakiet, odrzucić go albo nadal dopasowywać po nazwie, gdy nowa rzecz przejmie tę nazwę.

Nie przenoś założenia z jednego klienta na drugi. Sprawdź, co twój klient naprawdę robi z brakującym celem, najlepiej tworząc warunek celowo na maszynie testowej i obserwując, który proces dziedziczy wykluczenie.

Usuń ją przez właściciela

Jeśli lista pochodzi z profilu zarządzanego, lokalna edycja jest zmianą tymczasową, która zostanie przywrócona przy następnym połączeniu. Zmień profil albo zapytaj tego, kto go posiada, i potwierdź, że zmiana przetrwa ponowne połączenie. Jeśli lista jest lokalna, usuń wpis i sprawdź, czy klient zapisał konfigurację od nowa, zamiast trzymać starą w pamięci.

Pusta lista nie jest celem. Celem jest lista, której wpisy nadal odpowiadają rzeczywistym wymaganiom.

Potem przetestuj oba kierunki

Po porządkach sprawdź aplikację, która nadal powinna być wykluczona, oraz aplikację, która teraz powinna iść przez tunel. Potwierdź osobno zachowanie DNS, ponieważ polityka resolvera to inna kontrola niż lista wykluczeń. Potem połącz się jeszcze raz i przetestuj ponownie, bo przywrócony profil to najczęstszy sposób, w jaki porządki po cichu same się cofają.

Przy każdym pozostałym wykluczeniu trzymaj jednolinijkowy cel. To właśnie ta linia powstrzymuje listę przed staniem się muzeum i sprawia, że następne porządki to praca na pięć minut.