Dlaczego ruch debugowania bezprzewodowego nie dowodzi wycieku VPN

Włączyłeś debugowanie bezprzewodowe, podłączyłeś laptopa, a sesja działała dalej, gdy VPN był włączony. Wygląda to tak, jakby coś prześliznęło się obok tunelu. Prawie na pewno nie. Sesja debugowania i żądanie aplikacji do witryny to różne relacje sieciowe i tylko jedna z nich powinna przechodzić przez tunel.

Spotkałem się z tym błędem odczytu dwa razy: raz, gdy telefon i laptop były w tej samej sieci Wi-Fi, i raz po restarcie, gdy parowanie przetrwało. W obu przypadkach VPN robił dokładnie to, do czego został skonfigurowany.

Nazwij obserwację, zanim nazwiesz błąd

Przed twierdzeniem o wycieku mogą wystąpić trzy zdarzenia i nie są one wymienne. Narzędzie może odkryć usługę, urządzenie może zatwierdzić stację roboczą albo autoryzowana sesja może faktycznie przenosić polecenia i bajty. Zapisz, które widziałeś, bo każde dowodzi mniej, niż ludzie zakładają.

Odkrywanie to zwykle mDNS albo skanowanie portów. Parowanie to decyzja o rejestracji podjęta na telefonie, potwierdzona kodem wpisywanym przez użytkownika. Aktywna sesja oznacza, że ruch przeszedł między dwoma sparowanymi punktami końcowymi. Nic z tego nie opisuje, dokąd trafia żądanie HTTPS aplikacji.

Trzymaj cel, interfejs, rodzinę adresów, znacznik czasu i profil użytkownika powiązane ze zdarzeniem. Bez tych szczegółów obserwacji nie można porównać z zamierzoną polityką sieci lokalnej ani z wersją VPN działającą wtedy.

Dlaczego dwie ścieżki nigdy się nie spotykają

Debugowanie bezprzewodowe to połączenie przychodzące do urządzenia. adbd nasłuchuje na porcie powiązanym z interfejsem Wi-Fi, a stacja robocza łączy się z nim po parowaniu. Kierunek ma znaczenie: laptop wchodzi do telefonu, a nie odwrotnie. To przeciwieństwo wycieku wyjściowego.

Ruch internetowy aplikacji wychodzi przez interfejs tunelu instalowany przez VpnService, dopasowany według UID i reguł routingu. adbd to demon systemowy działający jako użytkownik shell, a nie aplikacja w tym zestawie routingu. Pozostaje na podstawowym łączu Wi-Fi, nawet gdy każda aplikacja jest przypięta do tunelu.

Tryb blokady wymusza tunel dla objętych aplikacji. Nie zamienia gniazda nasłuchującego w ścieżkę wyjścia.

Dlatego działająca sesja ADB i działający wyłącznik mogą współistnieć bez sprzeczności. Aby dowieść wycieku, trzeba obserwować kierunek, który powinien być zablokowany.

Jak naprawdę wygląda test wyjścia

Testuj objętą aplikację, a nie kanał debugowania. Celowo ustaw warunek awarii, następnie wykonaj jedno nowe żądanie i zapisz, co się stało.

1. Potwierdź, że VPN jest jedyną ścieżką: włącz VPN zawsze włączony z blokowaniem połączeń bez VPN.
2. Zatrzymaj VPN w obsługiwany sposób i potwierdź, że aplikacja zgłasza brak łączności.
3. Wyślij jedno nieszkodliwe żądanie z tej aplikacji i zanotuj, czy kończy się niepowodzeniem, czy powodzeniem.
4. Powtórz z włączonym, a potem wyłączonym debugowaniem bezprzewodowym, aby odizolować zmienną.

Zablokowane żądanie w tych warunkach jest dowodem. Udana sesja ADB nie jest, podobnie jak jeden ping z aplikacji terminala.

Jeśli żądanie rzeczywiście się powiedzie, gdy blokada jest włączona, zapisz UID aplikacji i jej uprawnienie VPN, aktywną sieć oraz wersję klienta. Taka kombinacja to prawdziwe odkrycie.

Parowanie przeżywa sesję

Parowanie to trwały stan, a nie uścisk dłoni, o którym można zapomnieć po teście kabla. Dokumentacja debugowania Androida opisuje bezprzewodowy przepływ pracy i zauważa, że relacja trwa, dopóki nie zostanie wyraźnie zapomniana lub dopóki autoryzacje nie zostaną odwołane.

Sprawdź, co jest jeszcze autoryzowane, zanim obwiniasz tunel. Otwórz Debugowanie bezprzewodowe, spójrz na Sparowane urządzenia i zapomnij wszystko, czego już nie rozpoznajesz. Uruchom adb devices ze stacji roboczej, aby zobaczyć, które wpisy nadal odpowiadają, i adb disconnect, aby usunąć nieaktualny. Wyłączenie debugowania bezprzewodowego całkowicie zamyka port nasłuchujący.

W sieci współdzielonej lub niezaufanej zostaw je wyłączone. Trwała autoryzacja w sieci, której nie kontrolujesz, to większy problem niż hipotetyczne obejście TUN.

Zanim zgłosisz ten błąd

Użyteczny raport nazywa dokładną granicę, która zawiodła. Podaj model urządzenia i wersję Androida, klienta VPN i wersję, czy blokada była włączona, pakiet aplikacji i UID oraz sieć, w której był telefon. Dodaj polecenie lub żądanie, które wywołało obserwację, oraz czas, kiedy to nastąpiło. Bez tego nikt nie odtworzy granicy, którą uznajesz za zepsutą.

Nie wyłączaj egzekwowania i nie wystawiaj debugowania w niezaufanej sieci, żeby test wyglądał dramatyczniej. To zmienia mierzony system i zostawia dowody, których nikt nie powtórzy.

Jeśli jedynym dowodem jest to, że ADB połączył się, gdy VPN był włączony, zmierzyłeś niewłaściwą ścieżkę. Najpierw uruchom ponownie test na poziomie aplikacji; odpowiedź zwykle przychodzi tam.