Jak czytać stan VPN i serwera proxy w zarządzanej aplikacji służbowej

Aplikacja służbowa zawodzi na zarządzanym telefonie, ktoś sprawdza przełącznik VPN, widzi, że jest włączony, i ogłasza ścieżkę zdrową. Tu kończy się większość takich diagnoz i jest to zbyt wcześnie: aktywny transport VPN nie mówi, że żądania tej aplikacji z niego korzystały, a proxy, które faktycznie obowiązuje, może być na aplikację lub wybierane przez plik PAC zamiast widoczne w Ustawieniach. Zacznij od konkretnej aplikacji i profilu, które debugujesz, a potem odczytaj własne spojrzenie platformy na ścieżkę.

Zacznij od aplikacji i jej profilu

Aplikacja z odznaką służbową zwykle działa w osobnym profilu z własną polityką sieciową. Prywatna przeglądarka na tym samym telefonie nie jest dla niej dowodem, podobnie jak wynik z urządzenia kolegi z innym zarządzaniem. Zanim cokolwiek przeczytasz, zanotuj, do którego profilu należy aplikacja.

W Ustawieniach wylistuj skonfigurowane wpisy VPN i zanotuj, do kogo należy każdy. W kompilacjach Samsunga etykiety menu przesuwają się między wersjami, więc opisuj wpis, a nie drogę do niego. Wyszarzony lub zarządzany wpis należy do tego, kto administruje urządzeniem; wyłączenie go jako eksperyment zmienia to, co próbujesz zmierzyć, i może być sprzeczne z polityką.

Odczytaj stan zgłaszany przez platformę

Wewnątrz istniejącej aktywności w twoich narzędziach wsparcia, na API 23 lub nowszym, stan sieci można odczytać bez wysłania choćby bajta. Wywołanie wymaga zwykłego uprawnienia manifestu ACCESS_NETWORK_STATE do odczytu możliwości.

val cm = getSystemService(android.net.ConnectivityManager::class.java) ?: return
val network = cm.activeNetwork
val caps = network?.let { cm.getNetworkCapabilities(it) }
val hasVpn = caps?.hasTransport(android.net.NetworkCapabilities.TRANSPORT_VPN)
val proxy = cm.defaultProxy

Każda wartość odpowiada na wąskie pytanie. Aktywna sieć to domyślna sieć procesu wywołującego w danej chwili. Sprawdzenie możliwości mówi, czy ta domyślna sieć jest oparta na VPN. Wywołanie proxy raportuje efektywne domyślne proxy HTTP, a zwrócony obiekt może opisywać albo proxy statyczne, albo skrypt PAC.

Jeśli potrzebujesz widoku dla poszczególnych sieci zamiast domyślnego, odczytaj właściwości łącza tej samej sieci i porównaj z cm.getLinkProperties(network)?.httpProxy. Proxy zainstalowane przez zarządzanie urządzeniem pojawia się w wywołaniu domyślnego proxy, a nie we właściwościach łącza, co jest szybkim sposobem odróżnienia proxy narzuconego przez politykę od tego, które dała sieć.

Trzymaj wynik w swoim kanale wsparcia, a nie w publicznym raporcie. Nazwy hostów proxy, adresy PAC i wewnętrzne sufiksy ujawniają, jak twoja organizacja kieruje ruch, i żaden z nich nie jest potrzebny do opisania awarii.

Interpretuj każde pole wąsko

Sieć null lub obiekt możliwości null oznacza, że stan sieci wywołującego był niedostępny albo zmienił się podczas odczytu. To nie znaczy, że nie ma VPN. Traktuj to jako nieznane i odczytaj ponownie po przejściu aplikacji na pierwszy plan, a nie jako wynik negatywny.

Transport VPN jest najsłabszym z pozytywów. Każda aplikacja trzymająca VpnService wytwarza go, łącznie z lokalną aplikacją filtrującą, która nigdy nie wysyła twojego ruchu donikąd. Wartość true mówi więc, że istnieje domyślna sieć oparta na VPN, a nie że użyto wyjścia twojej organizacji i z pewnością nie że doszło do inspekcji.

Domyślne proxy null oznacza, że to API nie raportuje żadnego domyślnego proxy HTTP dla efektywnej konfiguracji. Wyklucza bardzo niewiele: aplikacja może mieć własne ustawienie SOCKS, implementować własnego klienta HTTP albo być sterowana przez proxy na bramie, o którym urządzenie nigdy się nie dowie.

PAC to przypadek, który pokonuje odpowiedź jedną wartością. Skrypt może skierować jedno miejsce docelowe przez proxy, a inne wysłać bezpośrednio, więc dwa żądania tej samej aplikacji w ciągu sekundy mogą pójść różnymi ścieżkami. A aplikacja, która wiąże swoje gniazda z wybraną siecią albo wywołuje bindProcessToNetwork, nie ma obowiązku podążać za wartością domyślną.

Czego ten zrzut nie może ci powiedzieć

To nie historia. Nic tu nie zapisuje, którą ścieżką poszło żądanie, które zawiodło, a udany odczyt po awarii nie jest dowodem na awarię. To też nie inwentarz: dostajesz domyślną sieć procesu wywołującego, a nie listę prywatnych połączeń każdej aplikacji.

Nie mówi też nic o tym, co dzieje się nad gniazdem. Uścisk dłoni TLS, który zawodzi na zarządzanym urządzeniu, może być problemem magazynu zaufania, niezgodnością przypinania albo nazwą, której proxy odmawia, i żadne z nich nie pojawia się w odczycie łączności.

Dlatego obie połowy liczą się razem: zrzut zawęża, gdzie patrzeć, a własna diagnostyka aplikacji mówi, co faktycznie zawiodło.

Zgłoś to w formie, której administrator może użyć

Podaj dotkniętą aplikację, profil, znacznik czasu i dokładny etap, który zawiódł: rozwiązywanie nazw, połączenie TCP, uścisk dłoni TLS lub status HTTP. Dodaj wartości zrzutu tak, jak je odczytano, z nullami zapisanymi jako nulle, a nie jako brak. Zanotuj, czy inne aplikacje w tym samym profilu zawodzą tak samo, co oddziela problem aplikacji od problemu ścieżki w całym profilu.

Potem zatrzymaj się i pozwól właścicielowi ścieżki odpowiedzieć. Nie traktuj certyfikatu firmowego, adresu proxy ani wpisu VPN jako zgody na usunięcie zarządzania lub obejście zatwierdzonej trasy; to zamienia sprawę wsparcia w incydent polityki.

Umowa domyślnego proxy jest krótka i warta jednego przeczytania, bo dokładnie określa, które proxy raportuje wywołanie, a każde nadmierne odczytanie tego zrzutu zaczyna się od założenia, że raportuje więcej.