Always On VPN a VPN On Demand na iPhonie: co wdrożyć

On Demand otwiera tunel, gdy pasują jego reguły; zarządzany Always On wymusza pokrycie na nadzorowanych urządzeniach. Poradnik wyboru i dowodu, że to działa.

Dwa iPhone’y mogą oba twierdzić, że mają VPN, a zachowywać się zupełnie różnie. On Demand otwiera tunel, gdy pasuje reguła, a użytkownik nadal może go wyłączyć w Ustawieniach. Zarządzany Always On utrzymuje pokrycie wymuszone na nadzorowanym urządzeniu, także w momentach, gdy tunel nie może się podnieść. Wybieraj, pytając, co musi być prawdą, gdy użytkownik nic nie robi, a potem testuj przejścia, a nie stan ustalony. Poniższe kroki idą w kolejności, w jakiej wdrożenie naprawdę zawodzi.

Krok 1: ustal, co urządzenie może wymusić

Always On to funkcja dla urządzeń nadzorowanych. Jeśli flota nie jest nadzorowana, rozmowa kończy się, zanim się zacznie, i żaden klucz payload nie czyni nienadzorowanego telefonu wymuszonym. Potwierdź nadzór po stronie zarządzania i na urządzeniu, a następnie potwierdź, kto podpisał profil.

Na telefonie: Ustawienia, potem Ogólne, potem VPN i zarządzanie urządzeniem. Wpis profilu podaje jego właściciela, a profil osobisty zainstalowany ręcznie wygląda inaczej niż dostarczony przez usługę zarządzania. Nie wnioskuj o wymuszeniu z nazwy profilu ani z etykiety marketingowej dostawcy; etykieta nie jest polityką platformy.

Zapisz trzy fakty, zanim dotkniesz konfiguracji: nadzorowane czy nie, profil zarządzany czy osobisty i który klient niesie tunel. Każdy późniejszy krok zależy od tych trzech, a przenoszenie zachowania z telefonu osobistego na profil zarządzany to sposób, w jaki wdrożenie zostaje zatwierdzone na złej podstawie.

Krok 2: czytaj reguły on-demand, nie nazwę funkcji

On Demand to lista reguł ocenianych po kolei. Każda reguła podaje akcję i warunki, które ją wybierają, a warunki są najciekawsze: typ interfejsu, SSID Wi-Fi, sufiks domeny DNS albo URL sondy. Zestaw reguł, który nigdy nie pasuje, to funkcja, która nigdy się nie łączy.

<key>OnDemandRules</key>
<array>
  <dict>
    <key>Action</key><string>EvaluateConnection</string>
    <key>InterfaceTypeMatch</key><string>WiFi</string>
    <key>SSIDMatch</key><array><string>Office-WiFi</string></array>
  </dict>
</array>

Przeczytaj całą tablicę i zadaj dwa pytania do każdej reguły: czy ten warunek może kiedykolwiek być prawdziwy w tej flocie i co się dzieje, gdy nie pasuje żadna reguła? Sieci korporacyjne zmieniają nazwy punktów dostępowych, łączą SSID i zmieniają sufiksy DNS, a każda z tych zmian po cichu odrywa regułę od rzeczywistości.

Warunek sufiksu DNS najczęściej zawodzi w terenie, bo sufiks zgłaszany przez telefon w sieci gościnnej to nie ten, który obsługuje firmowy resolver. Zweryfikuj nazwę, którą urządzenie naprawdę rozwiązuje, zanim zaufasz regule.

Krok 3: testuj przejścia, nie statyczne połączenie

Tunel, który stoi, gdy na niego patrzysz, dowodzi bardzo niewiele. Wykonaj każde przejście świadomie i zapisz, co robi urządzenie, używając za każdym razem tego samego zasobu prywatnego, aby wyniki były porównywalne:

  • Dołącz do sieci, w której reguła powinna pasować, potem zażądaj zasobu prywatnego i potwierdź, że się wczytuje.
  • Przełącz na sieć komórkową z aplikacją w tle, potem wyciągnij ją na wierzch i powtórz żądanie.
  • Połącz się z Wi-Fi z portalem przechwytującym i sprawdź, czy portal jest osiągalny, czy wymuszanie blokuje go przed uwierzytelnieniem.
  • Wyłącz tunel ręcznie na nadzorowanym urządzeniu i sprawdź, czy wraca sam i jak szybko.

Wykonaj tę samą listę na urządzeniu nienadzorowanym, jeśli je masz. Różnica między oboma wynikami to rzeczywiste zachowanie wdrożenia i właśnie tego nigdy nie pokaże zrzut ekranu podłączonego tunelu.

Krok 4: poznaj dwa kształty awarii

Wymuszone pokrycie zawodzi przez blokowanie. Gdy tunel się nie zestawia, urządzenie traci zwykły dostęp do internetu wraz z zasobami prywatnymi, a użytkownik doświadcza telefonu online, którym nie można przeglądać. Ponowne łączenie i blokowanie to osobne obserwacje, więc rejestruj oba, zamiast traktować brak internetu jako jeden objaw.

On Demand zawodzi przez brak wyzwolenia. Reguła nie pasuje, nie pojawia się tunel, a zasób prywatny po prostu kończy się przekroczeniem czasu. Łatwo błędnie zdiagnozować to jako problem serwera, bo klient zachowuje się dokładnie tak, jak skonfigurowano.

Portal przechwytujący leży pomiędzy: potrzebuje łączności, zanim powstanie tunel, więc polityka blokująca wszystko do podniesienia tunelu wymaga udokumentowanej ścieżki przez portal. Zdecyduj o tym w projekcie, nie na help desku.

Krok 5: zweryfikuj, a potem przećwicz wycofanie

Weryfikacja należy do rzeczywistej ścieżki z nieszkodliwym ruchem: zażądaj zasobu prywatnego, który nie powinien być publiczny, potwierdź, jaki adres urządzenie pokazuje na zewnątrz, i powtórz po restarcie, aby zobaczyć sekwencję startu, nie tylko stan ciepły.

Potem przećwicz usuwanie na urządzeniu testowym, zanim będzie potrzebne w produkcji. Usunięcie profilu przywraca urządzenie do poprzedniego stanu, a wiedza, ile to trwa i co widzi użytkownik, jest częścią runbooka. Przewodnik bezpieczeństwa VPN Apple jest odniesieniem do tego, co platforma dokumentuje o tych politykach, i warto go przeczytać, zanim napiszesz konfigurację twierdzącą więcej niż platforma.

Trzymaj trzy fakty z pierwszego kroku obok zestawu reguł i wyników testów. Gdy następna osoba zapyta, dlaczego telefon łączy się w jednej sieci, a w innej nie, te notatki odpowiadają w minutę zamiast przebudowy.

Powiązane artykuły