Aplikacja firmowa wymaga VPN? Najpierw sprawdź te trzy warstwy

Komunikat mówi, że aplikacja potrzebuje VPN, ale zwykle aplikacja zgłasza objaw, a nie nazywa tego, co ją zablokowało. Trzy różne podmioty mogą wygenerować to zdanie: usługa prywatna, z którą rozmawia aplikacja, własny kod polityki aplikacji oraz warstwa zarządzania urządzeniem, która kontroluje profil służbowy. To, który z nich pyta, zmienia to, co powinieneś zrobić, i tylko jeden z trzech naprawia się przez podłączenie tunelu. Wcześniejsze znalezienie właściciela oszczędza ci ponownej instalacji klienta, który nigdy nie był problemem.

Co może sprawdzić sama aplikacja

Zanim założysz ukrytą regułę platformy, pamiętaj, że zwykła aplikacja może sprawdzić, czy transport VPN jest aktywny. ConnectivityManager zgłasza sieci przenoszące TRANSPORT_VPN, a brak NET_CAPABILITY_NOT_VPN mówi każdemu wywołującemu, że bieżąca ścieżka przechodzi przez tunel. Programista, który chce odmówić działania poza tunelem, może to zrobić za pomocą publicznych API i całkowicie bez narzędzi korporacyjnych.

Czego aplikacja w ten sposób nie widzi, to czyj to VPN. Flaga transportu mówi, że tunel istnieje, a nie że kończy się tam, gdzie oczekuje twoja organizacja.

Ścieżka usługi: prywatne nazwy i adresy

Najczęstsza uczciwa wersja komunikatu wcale nie jest kontrolą polityki. Aplikacja rozwiązuje wewnętrzną nazwę hosta, na przykład wiki lub punkt końcowy API, który istnieje tylko w firmowym widoku DNS, i wyszukiwanie kończy się niepowodzeniem, zanim uruchomi się jakikolwiek kod polityki. Tunel może być aktywny i przepuszczać ogólny ruch internetowy, podczas gdy podzielony DNS wysyła tę nazwę do resolvera, który nigdy o niej nie słyszał.

Objawy są tu wąskie. Jeden host zawodzi, pozostałe wywołania sieciowe aplikacji działają, a błąd pojawia się podczas wyszukiwania nazwy, a nie przy starcie. Wewnętrzne certyfikaty dodają drugi tryb awarii, ponieważ aplikacja przypięta do CA organizacji odrzuca certyfikat publiczny, nawet gdy pakiety płyną.

Podłączenie dowolnego komercyjnego VPN niczego z tego nie naprawia. Zmienia adres wyjściowy i pozostawia wewnętrzną nazwę równie nierozwiązywalną.

Warstwa polityki aplikacji

Aplikacja może też mieć własną bramę. Konfiguracje zarządzane pozwalają organizacji wysyłać pary klucz-wartość, które aplikacja deklaruje, a aplikacja odczytuje je przez RestrictionManager. Klucz, taki jak wymagana nazwa profilu lub lista dozwolonych sieci, jest całkowicie projektem programisty, egzekwowanym w kodzie aplikacji z dowolnym tekstem błędu, który wybierze ten kod.

To jest warstwa, na której sformułowanie zwykle się zdradza. Jeśli komunikat pojawia się natychmiast przy starcie, przed jakimkolwiek wywołaniem sieciowym, i wymienia politykę, profil lub administratora, prawdopodobnie patrzysz na logikę aplikacji, a nie na zgubiony pakiet.

Czytanie tego samego ograniczenia na urządzeniu prywatnym to ślepa uliczka. Urządzenia niezarządzane nie mają ograniczeń do odczytania, więc aplikacja wraca do dowolnej wartości domyślnej, z którą została zbudowana.

Warstwa platformy: zawsze włączone i blokada

Zarządzanie urządzeniem dodaje egzekwowanie, którego aplikacja nie może obejść. Kontroler polityki urządzenia może wywołać setAlwaysOnVpnPackage dla profilu służbowego, opcjonalnie z włączoną blokadą, a gdy blokada jest włączona, platforma odrzuca ruch, który nie przechodzi przez ten pakiet. Blokada jest widoczna jako stan systemu, a nie błąd aplikacji: inne aplikacje w profilu również przestają docierać do sieci.

Zakres ma znaczenie. VPN zawsze włączony konfiguruje się dla każdego użytkownika, więc pakiet profilu służbowego nie obejmuje twojego profilu prywatnego, a prywatny VPN nie spełnia pakietu profilu służbowego. Dwa profile, dwie niezależne polityki sieciowe, jedno urządzenie.

To także jedyna warstwa, w której niepowiązany VPN nie może pomóc, ponieważ polityka wskazuje jeden konkretny pakiet.

Rozróżnianie trzech

Przejdź przez sygnatury po kolei i zatrzymaj się na pierwszej, która pasuje. Jedna nazwa hosta zawodzi, podczas gdy wszystko inne się rozwiązuje, wskazuje na ścieżkę usługi. Natychmiastowa odmowa przy starcie z sformułowaniem polityki wskazuje na logikę aplikacji. Cały profil traci łączność za każdym razem, gdy zatwierdzony klient się rozłącza, wskazuje na blokadę. A aplikacja, która akceptuje dowolny tunel, sprawdza flagę transportu, a nie tożsamość twojej organizacji.

Przydatne dowody: dokładny tekst i jego czas, czy inne aplikacje w tym samym profilu nadal mają łączność, czy prywatna nazwa rozwiązuje się wewnątrz zatwierdzonego tunelu i czy urządzenie pokazuje odznakę służbową dla otwartej aplikacji.

Co wpisać w zgłoszeniu do pomocy

Zgłoszenie, które nazywa warstwę, jest kierowane poprawnie za pierwszym razem. Coś w rodzaju: aplikacja profilu służbowego otwiera się, lista zasobów zawodzi po połączeniu zatwierdzonego VPN, rozwiązywanie prywatnej nazwy zawodzi w dozwolonej diagnostyce, a inne aplikacje w profilu nadal działają. To czyta się jako problem trasy lub resolvera i pomija pętlę resetowania konta.

Jeśli zatwierdzonego VPN w ogóle nie ma, obsługiwaną ścieżką jest rejestracja lub ponowne udostępnienie przez administratora. Usunięcie profilu zarządzania, zainstalowanie niepowiązanego klienta lub sfałszowanie stanu sieci zmienia układ zabezpieczeń, zamiast go przywracać.

Zacznij od warstwy, nie od klienta. Trzy powyższe sygnatury zwykle rozstrzygają to w jednej sesji.