Dlaczego dzielone tunelowanie nie obejmuje aktualizacji twojej aplikacji

Dodajesz aplikację do listy wykluczeń dzielonego tunelowania, aplikacja łączy się z internetem bezpośrednio, a aktualizacje nadal zawodzą albo nadal wleką się przez tunel. Wykluczenie zadziałało. Objęło tylko inny proces niż ten, który wykonuje pobieranie, bo nowoczesny aktualizator rzadko jest tym samym plikiem wykonywalnym co okno aplikacji.

Mit: wykluczenie aplikacji wyklucza jej ruch

Dzielone tunelowanie według aplikacji dopasowuje proces, pakiet lub ścieżkę aplikacji, zależnie od platformy. Nie dopasowuje marki, funkcji ani intencji użytkownika. Gdy aplikacja przekazuje pobieranie pomocnikowi, współdzielonej usłudze platformy albo komponentowi przeglądarki, ten pomocnik ma własną tożsamość i własną ścieżkę przez tunel. Lista wykluczeń nie ma pojęcia, że oba procesy należą do tego samego produktu. Wie tylko, który wymieniłeś.

Reguła robi więc dokładnie to, co jej kazano. Założenie o tym, kto jest właścicielem przesyłu, było błędne, a naprawa zaczyna się od zidentyfikowania tego właściciela, a nie od dodawania kolejnych wykluczeń.

Znajdź właściciela przesyłu

W Androidzie aktualizację może pobrać współdzielony pakiet usługi, a nie wykluczony pakiet aplikacji, i reguła VPN dla aplikacji dotyczy pakietu, który otwiera gniazdo. W systemie Windows usługa aktualizacji może działać pod inną ścieżką wykonywalną niż aplikacja, więc reguła pasująca do ścieżki aplikacji jej nie obejmuje. W systemie macOS uprzywilejowany pomocnik lub demon aktualizacji systemu może wykonać przesył, podczas gdy aplikacja tylko o niego prosi.

Zidentyfikuj właściciela na podstawie dowodów: widoku aktywności sieciowej platformy, przechwycenia pakietów filtrowanego po procesie albo dokumentacji dostawcy, która nazywa komponent aktualizatora. Zgadywanie po nazwie procesu to sposób, w jaki dwa podobne pliki binarne są mylone, a niewłaściwy wykluczany.

Systemy aktualizacji często też dzielą pracę. Małe żądanie metadanych sprawdza wersję, a znacznie większe pobieranie pakietu trafia do hosta dostarczania treści lub do innej domeny. Sprawdzenie metadanych może się udać przez tunel, podczas gdy przesył pakietu utyka na hoście, który tunel trasuje inaczej. Ten podział wyjaśnia mylący raport, w którym aktualizacje są wykrywane, ale nigdy nie instalowane. Testuj samo pobieranie pakietu, z tego samego urządzenia i tej samej sieci, zamiast testować, czy aplikacja się otwiera.

Weryfikacja przetrwa zmianę trasy

Zmiana trasy nie zastępuje TLS, tożsamości wydawcy ani weryfikacji podpisu pakietu. Nie wyłączaj tych sprawdzeń tylko dlatego, że pobieranie udaje się dopiero po kliknięciu niejasnego ostrzeżenia o certyfikacie. Ostrzeżenie widoczne tylko na wykluczonej trasie jest ustaleniem, a nie przeszkodą. Zbadaj je, zanim poszerzysz obejście.

Na urządzeniu zarządzanym poproś o obsługiwany wyjątek zamiast dodawać szeroką regułę dla każdej usługi systemowej. Reguła wykluczająca wszystkie usługi współdzielone, aby naprawić jeden aktualizator, poszerza obejście znacznie poza pierwotne żądanie.

Przetestuj aktualizację, a następnie udokumentuj właściciela

Po zmianie połącz się ponownie i zweryfikuj zastosowaną regułę jeszcze raz, ponieważ niektóre klienty odbudowują trasowanie po ponownym połączeniu tunelu. Przeprowadź jeden pełny cykl aktualizacji: sprawdź, pobierz, zweryfikuj i zainstaluj. Udane sprawdzenie dowodzi tylko najmniejszej części trasy.

Zapisz właściciela przesyłu, hosty docelowe i zamierzoną trasę w tym samym miejscu co reguła dzielonego tunelowania. Inaczej następna zmiana mechanizmu aktualizacji po cichu unieważni wyjątek, a osoba, która go odziedziczy, nie będzie miała sposobu dowiedzieć się, dla którego procesu reguła została napisana.