Wykluczona aplikacja nadal online? Zasady dla aplikacji i tras się różnią

Wykluczenie pakietu to polecenie routingu, a nie blokada, więc strony ładowane po połączeniu VPN są oczekiwane, a nie dowodem awarii. Wykluczenie usuwa aplikację z tunelu zamiast ją blokować, a zwykła sieć niesie jej ruch. Spotykają się tu dwie odrębne polityki: jedna wybiera procesy, druga wybiera cele. Czytanie ich w tej kolejności wyjaśnia, dlaczego połączona ikona i działająca aplikacja nie są sprzecznością.

Dlaczego wykluczenie zostawia sieć otwartą

VpnService.Builder przyjmuje albo listę dozwolonych, albo listę zabronionych, nigdy obie. Tylko pakiety z listy dozwolonych są kierowane przez tunel. Lista zabronionych odwraca to: każdy pakiet poza wymienionymi korzysta z tunelu, a wymienione zachowują ścieżkę fizyczną. Pakiet niewymieniony na liście dozwolonych też jest poza tunelem, więc wykluczenie jest normalnym stanem większości aplikacji w tym trybie.

To czyni lokalny wpis zabronionych decyzją routingu, a nie regułą zapory. Jeśli wymaganiem jest uniemożliwienie aplikacji dotarcia do hosta, tunel musi ją objąć, a serwer lub lokalna polityka musi odrzucić ruch. Usunięcie aplikacji z tunelu zmienia tylko to, który interfejs niesie jej pakiety.

Przypadek Play Store to zwykły celowy przykład. Wykluczenie pakietu sklepu pozwala pobieraniom korzystać z połączenia podstawowego, gdy wyjście VPN przeszkadza w transferach, i pokazuje, że wykluczenie oznacza obejście, a nie blokadę.

Jeden profil, jedna lista

Konstruktor zgłasza wyjątek, jeśli użyte zostaną oba wywołania, więc profil przed tobą to albo lista dozwolonych, albo zabronionych. Ten jeden fakt decyduje, jak czytać każde późniejsze obserwacje. Sprawdź kod lub konfigurację zarządzaną przed tabelą routingu, bo lista decyduje, co znaczy reszta danych wyjściowych. Profil hybrydowy to nie stan, któremu można się przyglądać.

Różnica przewiduje też, co zrobi nowo zainstalowana aplikacja. Na liście dozwolonych zostaje na zewnątrz, dopóki ktoś jej nie doda, a na liście zabronionych domyślnie dołącza do tunelu.

Konfiguracje zarządzane pokazują ten sam wybór pod innymi nazwami kluczy, a niektóre konsole opisują go jako tryb VPN dla poszczególnych aplikacji, a nie jako listę. Zachowanie nadal sprowadza się do tych dwóch wywołań, więc prześledź ustawienie z powrotem do listy pakietów, zamiast ufać etykiecie. Jeśli etykieta i lista się różnią, wygrywa lista.

Podążaj za regułą UID do tabeli tunelu

Android daje każdej aplikacji własny identyfikator użytkownika Linuksa, a usługa VPN instaluje reguły polityki pasujące do zakresów UID. Pasujący ruch jest wysyłany do tabeli routingu, której trasa domyślna wskazuje urządzenie tun. Numer tabeli jest przydzielany dla każdej instancji VPN, więc zmienia się po ponownym połączeniu lub po utworzeniu drugiego profilu VPN.

Wyjście reguł to mapa. Każdy wiersz nazywa tabelę wyszukiwania, a ta tabela trzyma trasę domyślną, która decyduje, czy pasujące pakiety wejdą do tunelu.

adb shell ip rule show
adb shell ip route show table all
adb shell cmd package list packages -U | grep <package>

Najpierw uruchom trzecie polecenie, aby uzyskać UID, potem znajdź regułę, której zakres go zawiera. Ta reguła wskazuje numer tabeli, a ip route show table <n> z tym numerem pokazuje, czy istnieje trasa domyślna przez urządzenie tun. Jeśli tabela nie ma trasy domyślnej, aplikacja jest wybrana, ale nie ma ścieżki, co jest inną awarią.

Te polecenia wymagają kompilacji z możliwością debugowania albo urządzenia, na którym adb shell może odczytać stan sieci. Na telefonie produkcyjnym menedżer pakietów nadal odpowiada, ale inspekcja routingu może zostać odrzucona, więc zapisz, co możesz, a resztę uznaj za niepotwierdzoną.

Trasa zajmuje prefiks, a nie aplikację

Builder.addRoute zajmuje prefiksy docelowe dla tunelu. Profil, który dodaje tylko 10.0.0.0/8 wysyła ten prefiks przez tunel i zostawia każdy inny cel na ścieżce fizycznej. To zwykłe tunelowanie dzielone i jest niezależne od tego, które aplikacje wybrały reguły.

Konfiguracja wypychana przez serwer odzwierciedla ten sam model. Pojedyncze wypchnięcia tras dodają prefiksy, a dyrektywa redirect-gateway zastępuje trasę domyślną i przechwytuje wszystko dla aplikacji objętych tunelem. Usunięcie tej dyrektywy może zmniejszyć działający tunel do jednej podsieci bez żadnej zmiany na urządzeniu.

Wypchnięta trasa z nietypową bramą lub kwalifikatorem metrycznym też może się nie zainstalować. Preferuj prostą formę prefiksu i zostaw serwerowi przekazywanie oraz NAT.

Przeczytaj przecięcie, zanim zmienisz ustawienie

Tunel niesie przecięcie objętych procesów i żądanych celów. Objęta aplikacja, która prosi o adres spoza opublikowanych prefiksów, wychodzi przez sieć fizyczną. Zablokowany pakiet zostaje na zewnątrz nawet wtedy, gdy prosi o adres wewnątrz tych prefiksów. Żaden z przypadków nie jest błędem; oba to dwie polityki wykonujące swoją pracę.

VPN dla poszczególnych aplikacji może też zostawić powiązaną aplikację bez łączności. Gdy on-demand jest wyłączony, a tunel leży, aplikacja pozostaje związana z VPN dla poszczególnych aplikacji i nie ma odwrotu, co wygląda jak zepsuta aplikacja, a nie stan polityki. Włączenie on-demand albo usunięcie powiązania przez zarządzanie to zmienia.

Diagnozuj jedną oś naraz. Najpierw potwierdź zezwolenie lub blokadę, po drugie odczytaj zainstalowane reguły UID i tabele, a na końcu przetestuj drugą aplikację wobec tego samego celu. Druga aplikacja rozdziela wybór procesu od wyboru celu w jednym żądaniu.

Zapisz wynik jako aplikację, cel i numer tabeli. Właśnie tę trójkę musi zachować następna zmiana.