Aplikacja Android odmawia działania przez VPN: która warstwa decyduje

Gdy aplikacja Android przestaje działać dokładnie w chwili, gdy tunel się podnosi, odpowiadać mogą trzy różne rzeczy, a ich objawy wyglądają podobnie. Aplikacja może odczytać własny stan sieci telefonu i odmówić lokalnie. Serwer może sklasyfikować adres, z którego przychodzisz, i go odrzucić. Albo odmowa nie ma nic wspólnego z VPN. Poniższa kolejność najpierw zbiera dowody, a dopiero potem cokolwiek zmienia, ponieważ zmiana wyjścia jest najdroższym krokiem i najmniej prawdopodobnie pomoże, jeśli test jest lokalny.

Krok 1: ustal, kiedy aplikacja odmawia

Czas jest pierwszym wyróżnikiem. Wyczyść bufor logów, odtwórz awarię i sprawdź, co aplikacja zrobiła, zanim zgłosiła problem:

adb logcat -c
# reproduce the failure in the app
adb logcat -d | grep -iE 'vpn|network|connect|http' | tail -60

Jeśli aplikacja odmawia, zanim podjęta zostanie jakakolwiek próba połączenia wychodzącego, masz do czynienia z decyzją lokalną. Jeśli łączy się, coś wysyła, a potem pokazuje błąd, odrzucenie przyszło z drugiej strony. Jeśli aplikacja zawodzi identycznie przy wyłączonym tunelu, VPN nigdy nie był zmienną.

Traktuj ten czas jako dowód, a nie jako rozstrzygnięcie. Aplikacja może odtwarzać z pamięci podręcznej odpowiedź, a żądania w tle mogły się udać lub nie, zanim na nie spojrzałeś. Zanotuj znaczniki czasu ostatniego udanego żądania i błędu, nie tylko moment pojawienia się komunikatu.

Krok 2: odczytaj, jak telefon widzi sieć

Android udostępnia stan VPN jako cechę sieci, więc aplikacja nie potrzebuje listy komercyjnych dostawców, aby zauważyć aktywny tunel. Pyta usługę łączności o bieżącą sieć, a odpowiedź zawiera bit transportu VPN:

val cm = context.getSystemService(ConnectivityManager::class.java)
val caps = cm.getNetworkCapabilities(cm.activeNetwork)
val onVpn = caps?.hasTransport(NetworkCapabilities.TRANSPORT_VPN) == true

Ten test jest lokalny i tani, i wyjaśnia całą klasę zgłoszeń typu „ta aplikacja nie działa przez VPN” bez żadnej klasyfikacji po stronie zdalnej. To, co aplikacja widzi, nadal zależy od jej własnego kontekstu sieciowego, więc nie zakładaj, że każda aplikacja sprawdza każdy profil na urządzeniu.

Ze stacji roboczej ten sam stan zobaczysz na urządzeniu testowym za pomocą adb shell dumpsys connectivity i szukając wpisu sieci VPN. Porównaj przebieg z podniesionym tunelem i z opuszczonym, i zachowaj oba wyniki.

Krok 3: odczytaj, co naprawdę widzi serwer

Drugim obserwatorem jest usługa. Widzi adres źródłowy, który do niej dociera, i może działać na podstawie adresu, sieci hostingowej za nim, regionu, operatora lub sygnałów powiązanych z kontem i urządzeniem. Żaden z nich nie jest unikalną tożsamością, a współdzielenie adresów sprawia, że blokady uboczne są normalne: jeden ograniczony adres może wyłączyć niezwiązanych użytkowników za tym samym tłumaczeniem.

Uzyskaj adres tą samą ścieżką, której używa aplikacja, a nie z przeglądarki na laptopie. Na telefonie zwykłe żądanie do usługi echo adresu pokazuje, co odbiera druga strona, a porównanie tego z żądaniem przez sieć komórkową mówi, czy adres w ogóle się zmienił.

Jeśli aplikacja działa przez sieć komórkową, a zawodzi przez tunel przy tym samym koncie, odrzucenie jest po stronie zdalnej albo w polityce samej aplikacji. Jeśli zawodzi w obu przypadkach, VPN nie jest czynnikiem różnicującym i powinieneś przestać testować punkty końcowe.

Krok 4: dopasuj dowody do jednego z trzech werdyktów

Trzy kombinacje obejmują prawie każde zgłoszenie. Odmowa bez próby połączenia wychodzącego przy aktywnym tunelu wskazuje na lokalny test transportu. żądanie, które wychodzi i wraca z błędem, przekroczenie czasu dla konkretnego hosta lub komunikat o regionie wskazują na stronę zdalną. Awaria, która powtarza się przez sieć komórkową bez tunelu, wskazuje na konto, wersję aplikacji lub politykę samej usługi, i żadna zmiana VPN jej nie ruszy.

Zapisz werdykt wraz z dowodami, które go dały. Wartość tego kroku polega na tym, że przerywa pętlę, w której ktoś cztery razy zmienia węzły wyjściowe, aby naprawić test działający na samym telefonie.

Utrzymuje też uczciwość twierdzeń. Własny serwer zmienia punkt końcowy i jego wyjście do internetu; nie sprawia, że Android zapomina o aktywnej sieci VPN, i nie gwarantuje akceptacji przez usługę, która klasyfikuje adresy. Lokalny filtr może zadziałać na sieci VPN, której jesteś właścicielem, równie łatwo jak na komercyjnej.

Krok 5: wybierz wspieraną drogę i sprawdź ją

Zacznij od udokumentowanej polityki produktu i jego właściciela wsparcia. Wyślij wersję klienta, dokładny komunikat i wąskie okno awarii; nie przesyłaj pełnych zrzutów ruchu ani danych uwierzytelniających tylko po to, by udowodnić, że błąd istnieje.

Jeśli usługa zezwala na dostęp bezpośredni, a polityka urządzenia na to pozwala, wyłączenie dla pojedynczej aplikacji jest wspieranym mechanizmem i celowo usuwa tę aplikację z tunelu, zamiast ukrywać tunel. Ruch aplikacji wychodzi wtedy własną ścieżką, co jest decyzją polityczną, którą ktoś musi wziąć na siebie. W konfiguracji blokującej bez VPN wyłączona aplikacja może po prostu stracić łączność, więc przetestuj ten wariant, zanim obiecasz, że działa.

Po każdej zmianie powtórz test czasu z kroku pierwszego, potwierdź, że aplikacja działa, i upewnij się, że każda inna aplikacja nadal korzysta z tunelu. Następnie przywróć poprzednią konfigurację i sprawdź, czy awaria wraca, bo poprawka, której nie potrafisz odtworzyć, jest przypadkiem, który jeszcze spotkasz.