Android: Always-On i blokowanie bez VPN — wybierz właściwą parę

Always-On i blokowanie bez VPN to dwa ustawienia i włączenie pierwszego nie włącza drugiego. Właściwa para zależy od tego, do kogo należy urządzenie, które aplikacje obejmuje tunel i co dzieje się przed odblokowaniem.

Dwa przełączniki z różnymi obietnicami

Always-On obiecuje trwałość i restartuje usługę, gdy ta padnie; blokowanie obiecuje odcięcie: bez tunelu objęty ruch nie ma drogi na zewnątrz.

Trzecim czynnikiem jest zakres według aplikacji, który należy do klienta lub polityki zarządzania, a nie do dwóch przełączników systemowych; blokowanie bez decyzji o zakresie daje politykę szerszą lub węższą niż potrzeba.

Decyzja pierwsza: urządzenie zarządzane czy ustawienie użytkownika?

Na urządzeniu zarządzanym polityka trzyma Always-On i blokadę, a lokalny przełącznik może nie istnieć; zmieniaj wymaganie w polityce, nie na urządzeniu.

Na urządzeniu osobistym użytkownik decyduje, czy akceptuje brak sieci, gdy tunelu nie ma; blokowanie to wymiana dostępności i brak przełącznika nie jest powodem do rootowania.

Zakres jest na profil, nie na urządzenie: Android pozwala na jeden aktywny VPN na profil użytkownika.

Blokada w profilu służbowym nic nie mówi o stronie prywatnej, a test jednego kontekstu nie potwierdza drugiego.

Decyzja druga: blokować wszystko czy wyłączyć część aplikacji?

Wyłączenia według aplikacji w trybie blokowania bywają rozumiane odwrotnie: według Androida wyłączone aplikacje mogą stracić połączenie zamiast po cichu korzystać ze zwykłej sieci, więc wyłączenie nie jest zgodą na internet.

Wybierz świadomie: blokuj cały objęty ruch i zaakceptuj, że wyłączone aplikacje zostaną w ciemności, albo wyłącz blokowanie i zaakceptuj drogę zapasową; jeśli jedna aplikacja musi mieć zawsze połączenie, blokowanie jest złym narzędziem.

Decyzja trzecia: co dzieje się przed odblokowaniem i w portalu?

W większości klientów tunel nie działa, dopóki użytkownik nie odblokuje urządzenia, więc pierwsze chwile po starcie to luka, nie awaria; potwierdź to dla wdrażanego klienta.

Portale captive to druga krawędź: sieć hotelowa lub lotniskowa wymaga niezalogowanej sesji przeglądarki, a twarda blokada może uniemożliwić logowanie; wspieraną odpowiedzią jest zatwierdzony proces odzyskiwania z wyzwalaczem, maksymalnym czasem, osobą udzielającą i sprawdzeniem, że egzekwowanie samo wraca.

Dokumentacja klientów VPN Androida obejmuje Always-On, blokowanie, wyłączenia według aplikacji i zasadę jednego VPN na profil; przeczytaj ją, zanim zaprojektujesz z pamięci.

Przetestuj stan bez sieci, a potem napisz wiersz akceptacji

Użyj nieszkodliwego ruchu i obsługiwanego testu awarii: zwykłe połączenie, utrata tunelu, odzyskanie i restart przed odblokowaniem, i zanotuj, czy aplikacja zablokowała się zgodnie z planem.

Sprawdzaj zasób i resolver, nie ikonę, i osobno testuj urządzenie za telefonem, bo polityka telefonu nie ustanawia przekazywania dla klientów hotspotu.

Wiersz akceptacji jest konkretny i sprawdzalny: zamierzona aplikacja w zamierzonym profilu dociera do zatwierdzonego tunelu i pozostaje w wymaganym stanie blokady, gdy nie może. Przed podpisaniem:

• Always-On i blokowanie są ustawione tam, gdzie platforma je wspiera, a właściciel każdego ustawienia jest znany.
• Zakres aplikacji jest świadomy i potwierdzono, co dzieje się z wyłączonymi aplikacjami w trybie blokowania.
• Luka przed odblokowaniem i proces portalu captive są rozstrzygnięte, nie odkryte.
• Test awarii wykonano na klasie urządzeń, którą naprawdę wdrażasz.