Planowanie Wi-Fi, certyfikatów, VPN i serwera proxy dla urządzeń Apple w Sophos Mobile

Zakres: Sophos Mobile w Sophos Fusion (dawniej Sophos Central), iPhone i iPad z iOS/iPadOS. Ten materiał rozróżnia zasady urządzeń iOS (Device Policy) i zasady użytkowników iOS (User Policy). Nie jest przetestowaną instrukcją konfiguracji krok po kroku dla konkretnego tenanta, poradnikiem dotyczącym macOS ani zgodą na masowe wdrożenie produkcyjne. Najpierw sprawdź na docelowym urządzeniu wersję systemu, tryb rejestracji, nadzór (Supervision), typ zasady i funkcje dostępne we własnym tenancie.

⚠️ Nie odcinaj łączności: Nieprawidłowy certyfikat Wi-Fi/EAP, niedostępny urząd certyfikacji SCEP, wadliwy PAC/WPAD lub tunel VPN mogą przerwać także kanał zwrotny dla zadań MDM. Przed zmianami potwierdź dostęp do sieci niezależny od modyfikowanego profilu oraz lokalny sposób usunięcia awarii. Zapisane w konsoli wycofanie zmian nie dotrze automatycznie do urządzenia, które utraciło łączność.

Najpierw rozróżnij tryb zarządzania

Device Enrollment nie oznacza automatycznie nadzoru (Supervision): Automated Device Enrollment obejmuje urządzenie nadzorem, ale inne metody niekoniecznie. Apple User Enrollment nigdy nie zapewnia nadzoru i dotyczy danych zarządzanych, a nie całego prywatnego urządzenia. W przypadku BYOD przygotowania obejmują Managed Apple Account i zgodę użytkownika. Nie ma tam globalnego serwera proxy HTTP ani standardowego VPN obejmującego całe urządzenie, ani ustawień proxy w konfiguracji zarządzanej sieci Wi-Fi; Sophos nie może odczytać adresu MAC, UDID ani IMEI na potrzeby identyfikacji przez NAC.

Sophos ogranicza profilową metodę User Enrollment do iOS/iPadOS 17 lub starszych wersji; nie oznacza to ogólnego wycofania User Enrollment w trybie account-driven. Wyrejestrowanie usuwa z urządzenia zarządzany wolumin APFS i zarządzane konto Apple; nie jest to uniwersalny sposób wycofania konfiguracji Wi-Fi lub VPN. Apple opisuje VPN dla poszczególnych aplikacji jako możliwą funkcję User Enrollment, a nie jako dowód, że w Sophos działa przypisywanie aplikacji do VPN.

Planuj Wi-Fi razem z łańcuchem certyfikatów

Odizoluj pilotaż BYOD przed każdą zmianą: W przypadku zasad użytkowników iOS/iPadOS Sophos automatycznie synchronizuje zmiany przy każdym ponownym połączeniu urządzenia z Sophos Mobile; ręczne Update devices nie jest do tego potrzebne. Dlatego używaj osobnej zasady użytkownika przypisanej wyłącznie do zatwierdzonego urządzenia testowego BYOD i sprawdzaj jej aktualne przypisania oraz liczbę urządzeń docelowych przed edycją i przed Save. Nie zmieniaj w pilotażu zasady przypisanej już wspólnie do produkcyjnych urządzeń BYOD. Późniejsze przypisanie do wybranych urządzeń testowych nie ogranicza synchronizacji zmiany na innych urządzeniach, do których ta sama zasada jest już przypisana. Ta reguła zakresu dotyczy również zmian certyfikatów i korekt przy wycofywaniu konfiguracji; sama synchronizacja nie potwierdza działania sieci ani drogi powrotnej do MDM.

Kto kogo weryfikuje? W firmowej sieci Wi-Fi z EAP (uwierzytelnianie między urządzeniem a siecią) urządzenie sprawdza nazwę i łańcuch certyfikatów serwera RADIUS. Przy logowaniu opartym na certyfikacie RADIUS z kolei sprawdza wystawioną tożsamość klienta. CA serwera i tożsamość klienta pełnią więc różne funkcje. Wybór Identity certificate w konfiguracji Wi-Fi wymaga konfiguracji Client certificate w tej samej zasadzie, a certyfikat serwera w sekcji Trusted certificates wymaga znajdującej się tam konfiguracji Root certificate.

Wyłącznie fikcyjne przykłady — nie kopiuj ich: radius.test.invalid jako nazwa serwera, Test-CA jako zaufany urząd certyfikacji serwera oraz CN=Testperson,OU=Pilot,O=Beispiel jako X.500 Subject (pola tożsamości klienta). Zastąp wszystkie wartości nazwami, CA i polami tożsamości potwierdzonymi przez własny zespół PKI/RADIUS. Na urządzeniu testowym sprawdź, czy skonfigurowana tożsamość serwera odpowiada rzeczywistemu łańcuchowi oraz czy RADIUS akceptuje wystawiony certyfikat klienta. Certyfikat główny to certyfikat X.509 w formacie PEM/DER, a importowany certyfikat klienta ma format PKCS#12 (.pfx). Przesłanego pliku .pfx nie można automatycznie użyć ponownie w różnych zasadach: jeśli potrzebujesz certyfikatu klienta w innej zasadzie, musisz przesłać go tam ponownie. Sprawdź pochodzenie CA, własność klucza, okres ważności i zamierzone zastosowanie. Przesłanie certyfikatu głównego CA nie dowodzi, że wszystkie aplikacje będą mu ufać.

W przypadku Root certificate w zasadzie urządzenia iOS otwórz konfigurację na stronie Edit policy przez Add configuration > Root certificate. Za pomocą Upload a file wybierz plik X.509 w formacie PEM/DER i otwórz go przyciskiem Open. Po przesłaniu pliku Certificate name wyświetla nazwę wyróżniającą (DN) wystawcy, a nie tożsamość klienta. Zapisz konfigurację przyciskiem Apply, a następnie zapisz zasadę przyciskiem Save na stronie Edit policy. Według Sophos przypisanie zasady instaluje przesłany certyfikat główny na urządzeniu. Samo wyświetlenie i zapisanie nie potwierdzają zaufania, ważności ani pomyślnej instalacji. Każdy kolejny certyfikat główny wymaga osobnej konfiguracji Root certificate w tej samej zasadzie.

W przypadku Root certificate w zasadzie użytkownika iOS Sophos opisuje import na stronie Edit policy przez Add configuration > Root certificate. Za pomocą Upload a file wybierz plik X.509 w formacie PEM/DER i otwórz go przyciskiem Open. Po przesłaniu pliku Certificate name wyświetla nazwę wyróżniającą wystawcy. Zapisz konfigurację przyciskiem Apply, a następnie zapisz zasadę przyciskiem Save na stronie Edit policy. Dla każdego kolejnego certyfikatu głównego dodaj osobną konfigurację Root certificate. Według Sophos przypisanie zasady użytkownika instaluje certyfikat na urządzeniu; w ramach tej samej zasady można go użyć na przykład jako certyfikatu serwera EAP w sieci Wi-Fi. Informacja wyświetlona po przesłaniu pliku i zapisana zasada nie potwierdzają pomyślnej instalacji, zaufania do certyfikatu ani działającego logowania do Wi-Fi.

W konfiguracji Client certificate w zasadzie urządzenia iOS wybierz najpierw Upload a file w polu File, a następnie plik certyfikatu PKCS#12 (.pfx). W polu Certificate name Sophos Mobile wyświetla nazwę odczytaną z pliku certyfikatu. Sama nazwa nie potwierdza zaufania, ważności ani pomyślnej instalacji.

Przed konfiguracją SCEP: Jeśli korzystasz z połączenia SCEP skonfigurowanego w Sophos setup za pomocą poniższych zmiennych, najpierw sprawdź wymagania wstępne SCEP i procedurę obsługi certyfikatów: osiągalność CA z Sophos Fusion, regionalnie ograniczone reguły zapory oraz — dla tej udokumentowanej ścieżki z Windows CA — konto uprawnione do tworzenia challenge i rejestracji certyfikatów. Przed dodaniem SCEP umieść certyfikat CA serwera SCEP jako Root certificate w tej samej zasadzie. Zaufanie do tego serwera jest odrębne od zaufania do serwera RADIUS i wystawionej tożsamości klienta; nie oznacza to, że Windows jest wymagany dla każdej bezpośredniej implementacji SCEP.

SCEP (Simple Certificate Enrollment Protocol) pozwala urządzeniu wystąpić do CA o certyfikat. Potrzebny jest do tego osiągalny adres URL CA lub prawidłowo skonfigurowana zmienna serwera proxy SCEP w Sophos. Uzgodnij z zespołem PKI pola X.500 Subject i SAN/UPN (dodatkowe nazwy tożsamości), challenge, parametry ponawiania oczekujących wniosków, długość klucza i bity użycia zgodnie z własnym CA. W konfiguracji SCEP w zasadzie urządzenia iOS ważne są następujące decyzje:

• Punkt końcowy i nazwa CA: URL to adres internetowy serwera CA. %_SCEPPROXYURL_% odwołuje się do adresu URL serwera na karcie SCEP strony Sophos setup. CA name to nazwa rozpoznawana przez CA; może na przykład służyć do rozróżniania instancji CA. Potwierdź z zespołem PKI nazwę oczekiwaną przez własny CA. To pole nie jest nazwą wyświetlaną w Certificate name dla importowanego certyfikatu ani przykładową nazwą zaufanego CA serwera RADIUS.
• Tożsamość użytkownika lub urządzenia: Subject może zawierać symbole zastępcze danych użytkownika lub właściwości urządzenia. Sophos podaje CN=%_USERNAME_% dla użytkownika oraz CN=%_DEVPROP(SerialNumber)_% dla iPhone’a lub iPada. Są to udokumentowane przykłady składni, a nie wartości sprawdzone dla Twojego tenanta. Uzgodnij docelową tożsamość z zespołem PKI i sprawdź, czy dane są dostępne oraz czy Subject po zastąpieniu symboli jest prawidłową nazwą X.500. BYOD: Udokumentowany symbol zastępczy numeru seryjnego nie dowodzi, że w User Enrollment da się ustalić tożsamość na podstawie tego numeru; Sophos nie może tam odczytać identyfikatorów urządzenia. Sprawdź pola Subject i wystawienie certyfikatu z udziałem osoby testującej.
• Typ i wartość SAN: W polu Type of Subject Alternative Name wybierz typ zatwierdzony przez zespół PKI i wpisz odpowiednią wartość w Value of Subject Alternative Name. RFC 822 name oznacza prawidłowy adres e-mail. Dla tej konfiguracji SCEP w iOS Sophos opisuje DNS name jako nazwę DNS serwera CA, a Uniform resource identifier jako jego w pełni kwalifikowany adres URL — nie jako nazwę serwera RADIUS ani adres challenge. AD user logon name jest odrębną pozycją i oznacza UPN ustawiony w Active Directory. Challenge to adres internetowy, pod którym urządzenie otrzymuje hasło challenge z serwera SCEP. %_CACHALLENGE_% odwołuje się do adresu URL challenge skonfigurowanego na karcie SCEP strony Sophos setup, a nie do samego hasła. Nie umieszczaj rzeczywistych sekretów w publicznych przykładach ani zgłoszeniach.
• Oczekujące wnioski: Retries określa liczbę ponownych prób, gdy serwer odpowiada pending; nie jest to ogólny licznik ponowień dla wszystkich błędów sieciowych. Retry delay to odstęp między tymi próbami w sekundach. Uzgodnij liczbę prób i odstęp z zespołem PKI; nie myl ich z odnawianiem certyfikatu.
• Klucz i zastosowanie: Key size oznacza rozmiar klucza publicznego w wystawionym certyfikacie i musi odpowiadać rozmiarowi skonfigurowanemu na serwerze SCEP. Certificate usage określa dozwolone zastosowanie: Use as digital signature dla podpisów cyfrowych, Use for encryption dla szyfrowania danych. Wybór musi odpowiadać wymaganiom PKI i usłudze docelowej; nie potwierdza pomyślnego logowania do Wi-Fi/VPN ani szyfrowania całego ruchu urządzenia.

Podczas tworzenia zasady dostępne jest pole SCEP renewal interval. Uzgodnij z zespołem PKI interwał, datę wygaśnięcia, unieważnianie i wymianę certyfikatów; ustawienie interwału nie gwarantuje ani pomyślnego odnowienia, ani przywrócenia urządzenia, które pozostało offline.

Zastępowanie symboli tożsamości w zasadach urządzeń i użytkowników: W powyższym przykładzie CN=%_USERNAME_% symbol %_USERNAME_% jest zastępowany wartością Exchange Login użytkownika przypisanego do urządzenia, niekoniecznie jego nazwą wyświetlaną i nie automatycznie jego AD UPN. Przed przypisaniem sprawdź właściwe powiązanie z użytkownikiem i wartość tej właściwości; Subject po zastąpieniu nadal musi być prawidłową nazwą X.500 zatwierdzoną przez zespół PKI. AD user logon name pozostaje odrębnym polem UPN.

Dla SCEP w zasadzie użytkownika iOS określ punkty końcowe oddzielnie. URL to adres internetowy serwera CA. Zmienna %_SCEPPROXYURL_% odwołuje się do adresu URL serwera na karcie SCEP strony Sophos setup. Challenge to adres URL służący do pobrania hasła challenge z serwera SCEP, a nie samo hasło. %_CACHALLENGE_% odwołuje się do adresu URL challenge skonfigurowanego tam na karcie SCEP. Podobnie jak w opisanych wyżej parametrach wniosków, Retries zlicza wyłącznie ponowienia po odpowiedzi pending; Retry delay określa odstęp między nimi w sekundach. Key size musi odpowiadać rozmiarowi klucza publicznego skonfigurowanemu na serwerze SCEP. Potwierdź te parametry z zespołem PKI; nie są one interwałami odnawiania ani dowodem pomyślnego wystawienia certyfikatu.

Firmowa sieć Wi-Fi i prywatny adres Wi-Fi

W odizolowanym pilotażu Wi-Fi dla urządzenia poniższa procedura łączy ustawienia sieci z przypisaniem zasady. Najpierw zapewnij niezależny dostęp do sieci i drogę powrotną opisane w sekcji pilotażu; nie edytuj zasady przypisanej do urządzeń produkcyjnych.

1. W Policies otwórz platformę Apple odpowiednią dla docelowego urządzenia, utwórz zasadę urządzenia przyciskiem Create i wpisz nazwę, opis oraz nazwę organizacji. Na stronie Edit policy dodaj konfigurację Wi-Fi przez Add configuration i otwórz jej nazwę, aby ją edytować. Dla sieci Enterprise najpierw przygotuj wymagane certyfikaty klienta i certyfikaty główne w tej samej zasadzie, zgodnie z opisem powyżej; Apply w konfiguracjach certyfikatów głównych nie zastępuje Save dla całej zasady.
2. W SSID wpisz nazwę Wi-Fi potwierdzoną przez zespół sieciowy, a Security type dopasuj do rzeczywistej metody i jej wariantu Personal/Enterprise. Personal wymaga hasła Wi-Fi; dla Enterprise zastosuj opisane niżej ustawienia EAP, logowania i zaufania. Connect automatically automatycznie łączy z dostępną siecią; Hidden network oznacza sieć, która nie rozgłasza SSID. Wybieraj obie opcje zgodnie z docelową siecią, a nie jako dowód bezpieczeństwa.
3. Sprawdź wszystkie konfiguracje i zapisz zasadę przyciskiem Save na stronie Edit policy. Następnie skorzystaj z procedury „Tworzenie i przypisywanie zasady”: wybierz zapisaną zasadę pilotażową, zaznacz wyłącznie zatwierdzone pojedyncze urządzenia testowe i sprawdź listę oraz liczbę przed Finish. Uwzględnij opisane tam zastrzeżenia dotyczące harmonogramu i iPadOS. Potem osobno obserwuj status zadania/przypisania, rzeczywiste logowanie do Wi-Fi i zgłoszenie urządzenia do MDM zgodnie z poniższymi kryteriami; zapisanie i przypisanie nie są potwierdzonymi wynikami połączenia.

W konfiguracji Wi-Fi w zasadzie urządzenia iOS najpierw wybierz Security type odpowiedni dla sieci. W wariancie Personal dostępne jest hasło Wi-Fi. Dopiero wariant Enterprise udostępnia Protocols, Authentication i Trusted certificates. W sekcji Accepted EAP types uzgodnij z zespołem RADIUS metody akceptowane przez urządzenie na potrzeby logowania do sieci. Opisane wyżej certyfikaty klienta i certyfikaty główne pozostają powiązane z tą samą zasadą.

W sekcji Authentication zasady urządzenia iOS pole User to nazwa użytkownika Wi-Fi, a Password to hasło Wi-Fi dla logowania z użyciem danych uwierzytelniających. Według Sophos Require password on each connect wysyła hasło przy każdym uwierzytelnianiu; opcja nie obiecuje interaktywnego pytania o hasło. Uzgodnij ścieżkę użycia danych uwierzytelniających i ten wybór z zespołem RADIUS. Przy logowaniu opartym na certyfikacie wybierz zamiast tego odpowiedni Identity certificate z konfiguracji Client certificate w tej samej zasadzie urządzenia. Zależnie od wybranej ścieżki sprawdź na urządzeniu testowym akceptację danych uwierzytelniających lub certyfikatu klienta przez RADIUS; tożsamość serwera i łańcuch zaufania wymagają osobnej weryfikacji w obu przypadkach.

W przypadku TTLS Internal identity oznacza protokół logowania użytkownika wewnątrz tunelu. Nie jest to tożsamość zewnętrzna. Dla EAP-FAST można skonfigurować Protected Access Credential (PAC); ten PAC nie jest skryptem automatycznej konfiguracji proxy. Uzgodnij z zespołem RADIUS protokół TTLS i, w razie potrzeby, dane uwierzytelniające EAP-FAST oraz sprawdź logowanie na docelowym urządzeniu. Bez tych ustaleń wyłącz dany wariant EAP z zakresu pilotażu.

W przypadku EAP ustaw obie granice TLS albo pozostaw obie nieustawione. Sophos opisuje Outer identity dla TTLS, PEAP i EAP-FAST oraz wymaga tożsamości zewnętrznej dla TLS 1.3. Nie podawaj w niej nazw użytkowników ani poufnych danych, ponieważ tożsamość zewnętrzna jest przesyłana jawnym tekstem. W razie potrzeby zespół PKI/RADIUS musi sprawdzić, czy anonimowa tożsamość zewnętrzna z odpowiednią domeną (realm) zapewnia prawidłowe kierowanie żądań. Obserwuj wynegocjowane logowanie i wersję TLS na urządzeniu testowym; sam wybór nie potwierdza pomyślnego połączenia.

Turn off private address powoduje, że urządzenie używa w tej sieci Wi-Fi swojego sprzętowego adresu MAC zamiast adresu generowanego przez iOS dla danej sieci. Ogranicza to prywatność. Używaj tej opcji tylko wtedy, gdy urządzenie bezwzględnie musi identyfikować się tym samym adresem MAC w różnych własnych sieciach. Według Sophos Synchronized Security nie działa z prywatnymi adresami MAC: Sophos Fusion Wireless zna tylko adres prywatny, a Sophos Mobile tylko adres sprzętowy. Samo wyłączenie nie gwarantuje jednak działania Synchronized Security; sprawdź powiązanie i oczekiwane zachowanie w docelowej sieci. Nie traktuj tego jako obejścia NAC dla BYOD. Przy User Enrollment Sophos nie ma dostępu do adresu MAC na potrzeby NAC.

Również dla Wi-Fi w zasadzie użytkownika iOS Sophos rozróżnia Personal i Enterprise w polu Security type. Personal używa hasła Wi-Fi. Protocols, Authentication i Trusted certificates są dostępne tylko dla Enterprise. Przy logowaniu z użyciem danych uwierzytelniających User to nazwa użytkownika Wi-Fi, a Password to hasło Wi-Fi. Według Sophos Require password on each connect wysyła hasło przy każdym uwierzytelnianiu. Uzgodnij ten wybór z zespołem RADIUS; nie traktuj go jako zapewnienia, że użytkownik będzie proszony o hasło. Przy logowaniu opartym na certyfikacie wybierz zamiast tego odpowiedni Identity certificate z konfiguracji Client certificate w tej samej zasadzie użytkownika. Certyfikat serwera w sekcji Trusted certificates również wymaga konfiguracji Root certificate w tej zasadzie. Certyfikat klienta i jego akceptację przez RADIUS stosuj jako kryterium weryfikacji tylko dla logowania opartego na certyfikacie.

Według opisu Wi-Fi omówione wyżej decyzje dotyczące EAP obowiązują również dla tej zasady użytkownika iOS. Uzgodnij Accepted EAP types z metodą logowania do sieci, dla TTLS ustal protokół w Internal identity, a dla EAP-FAST w razie potrzeby Protected Access Credential (PAC). Te dane uwierzytelniające nie są skryptem PAC serwera proxy. Ustaw obie granice TLS albo pozostaw obie nieustawione. Outer identity jest opisane dla TTLS, PEAP i EAP-FAST oraz wymagane dla TLS 1.3. Uwzględnij powyższe uwagi o przesyłaniu jawnym tekstem i domenie (realm). Nie wyciągaj z tego wniosku o dostępności wszystkich opcji we własnym tenancie ani o pomyślnym logowaniu; wykluczenie zarządzanego proxy Wi-Fi i zastrzeżenie dotyczące MAC/NAC przy User Enrollment nadal obowiązują.

Serwer proxy i VPN to różne rodzaje ingerencji

• Serwer proxy Wi-Fi: W zasadzie urządzenia iOS można skonfigurować go ręcznie lub przez PAC (plik z regułami proxy). W przypadku Apple User Enrollment konfiguracja Wi-Fi nie obsługuje serwera proxy. Sophos wskazuje tam WPAD (automatyczne wykrywanie serwera proxy) w punkcie dostępowym oraz wybranie przez użytkownika automatycznej konfiguracji serwera proxy HTTP w ustawieniach Wi-Fi jako możliwe obejście — nie jako zdalnie zarządzaną konfigurację proxy dla BYOD. Testuj osobno PAC/WPAD, DNS i osiągalność.
• Globalny serwer proxy HTTP: Sophos dopuszcza tę konfigurację urządzenia iOS tylko dla urządzeń nadzorowanych; ręcznie, z serwerem, portem i ewentualnie danymi uwierzytelniającymi, albo automatycznie, przez adres URL PAC. W trybie ręcznym Server to nazwa lub adres IP serwera proxy HTTP, a Port to jego numer portu. Authentication to nazwa użytkownika używana do połączenia z serwerem proxy, a Password to hasło tego użytkownika. Nie jest to obietnica działania dla BYOD ani odporności na awarie.
• VPN obejmujący całe urządzenie: Zasada urządzenia iOS przewiduje typ połączenia, serwer i uwierzytelnianie; przy Custom SSL/TLS musi być zainstalowana aplikacja dostawcy. Nie przenoś tej konfiguracji na Apple User Enrollment: Apple nie zezwala tam na standardowy VPN obejmujący całe urządzenie.
• VPN dla poszczególnych aplikacji: Osobna konfiguracja dla wybranych aplikacji, nie tożsama z VPN urządzenia. Sprawdź oddzielnie aplikację dostawcy przy Custom SSL/TLS, serwer, uwierzytelnianie, opcjonalne certyfikaty/proxy, połączenie na żądanie (On-Demand) oraz reguły domen dla Safari/innych przeglądarek, kalendarza, kontaktów i poczty. Sprawdź też rzeczywisty zakres działania Send all traffic through VPN; nie wyciągaj z samej nazwy wniosku o uniwersalnej izolacji aplikacji ani o działaniu na całym urządzeniu. Dokumentacja Sophos jest tu niespójna: Opis User Policy obejmuje VPN dla poszczególnych aplikacji, ale instrukcja przypisania aplikacji podaje jako warunek i opcję wyboru jedynie Device Policies. Dlatego nie twierdź, że istnieje działająca ścieżka przypisania w BYOD: najpierw potwierdź ją w aktualnym tenancie na aplikacji i urządzeniu testowym.

VPN urządzenia: dostawca, logowanie i droga ruchu

Poniższe informacje dotyczą konfiguracji VPN w zasadzie urządzenia iOS, a nie konfiguracji VPN dla poszczególnych aplikacji ani Apple User Enrollment. Sprawdź dostępność i obsługę dostawcy we własnym tenancie. Connection name to nazwa połączenia wyświetlana na urządzeniu. W Server wpisz nazwę hosta lub adres IP serwera VPN; potwierdź właściwy punkt końcowy z osobą odpowiedzialną za VPN.

• W polu Connection type wybierz odpowiedniego dostawcę lub typ połączenia. Dla aplikacji dostawcy VPN z App Store Sophos opisuje Custom SSL/TLS. Aplikacja musi być zainstalowana; w polu Identifier (reverse DNS format) wpisz jej identyfikator w formacie odwróconej nazwy DNS. Jeśli dostawca określa własne parametry połączenia, wpisz potwierdzone klucze i wartości w Third-party settings jako właściwości połączenia. Nie kopiuj kluczy ani wartości z konfiguracji innych dostawców.
• User authentication dotyczy logowania użytkownika. Account to konto użytkownika połączenia VPN; Group może określać wymaganą dla niego grupę uwierzytelniania. W Password podaj hasło VPN, a w Certificate certyfikat uwierzytelniania VPN. Uzgodnij z osobą odpowiedzialną za VPN, czy grupa jest potrzebna i jaka tożsamość ma być używana. Te dane uwierzytelniające nie są danymi do serwera proxy.
• Device authentication jest odrębną konfiguracją. W wariancie Keys (Shared Secret)/Group name podaj wymaganą grupę w Group name, a klucz współdzielony w Keys (Shared Secret). Sophos wymienia tu Use hybrid authentication i Request password, ale na tej stronie opisuje jedynie wybór zależny od potrzeb. Ich działanie i wymagany wybór nie są tutaj wyjaśnione; uwzględnij te dwie opcje w pilotażu dopiero po potwierdzeniu przez dostawcę. W Certificate wybierz wymagany certyfikat uwierzytelniania urządzenia. Według Sophos Including user PIN opcjonalnie uwzględnia PIN użytkownika w uwierzytelnianiu urządzenia. Nie stosuj żadnego z tych wariantów do wszystkich dostawców bez weryfikacji i nie zapisuj rzeczywistych kluczy ani PIN-ów w zgłoszeniach.
• Send all traffic through VPN to ustawienie kierujące cały ruch przez to połączenie VPN. Sophos opisuje je jako wysyłanie całego ruchu przez VPN. Sprawdź rzeczywistą drogę ruchu na urządzeniu testowym dla wybranego dostawcy i trybu tunelu oraz oddzielnie skontroluj kanał zwrotny MDM. Nie jest to dowód objęcia całego ruchu bez wyjątków ani izolacji aplikacji.
• W sekcji Proxy określ serwer proxy tego połączenia VPN. No proxy oznacza brak serwera proxy dla połączenia. Przy Manually wpisz adres serwera proxy i port w Server and port; Authentication to nazwa użytkownika proxy, a Password to jego hasło. Przy Automatic podaj w Proxy server URL adres URL serwera z ustawieniami proxy. Ten wybór nie jest konfiguracją proxy Wi-Fi ani globalnego proxy HTTP; nie wyciągaj z niego wniosku o wymogu nadzoru ani odporności na awarie.
• Provider type rozróżnia poziom transportu, a nie dostawcę z Connection type. App proxy przenosi ruch w tunelu VPN na poziomie aplikacji, a Packet tunnel na poziomie sieci. App proxy nie jest zatem tożsame z VPN dla poszczególnych aplikacji. Na docelowym urządzeniu trzeba sprawdzić, który wariant obsługuje dostawca i jaki ruch faktycznie obejmuje.

VPN dla poszczególnych aplikacji: dane wejściowe i uruchamianie połączenia

Dla Per app VPN w zasadzie urządzenia iOS Sophos opisuje następujące dane wejściowe i zachowania; ich działanie należy sprawdzić w pilotażu. Te informacje nie rozwiązują wspomnianej wyżej sprzeczności dotyczącej przypisywania aplikacji w zasadach użytkowników iOS.

Dla Per app VPN, zarówno w zasadach urządzeń iOS, jak i w zasadach użytkowników iOS, Connection name to nazwa połączenia wyświetlana na urządzeniu. Jest to widoczna etykieta połączenia, a nie identyfikator aplikacji dostawcy w formacie odwróconej nazwy DNS, adres serwera ani konto użytkownika.

• Aplikacja dostawcy: Jeśli dostawca VPN ma w App Store aplikację zapewniającą połączenie VPN, wybierz Custom SSL/TLS. Ta aplikacja VPN musi być zainstalowana na urządzeniu; w Identifier (reverse DNS format) wpisz jej identyfikator w formacie odwróconej nazwy DNS, a nie identyfikator aplikacji biznesowej, której ruch ma być tunelowany.
• Logowanie do VPN: Server to nazwa hosta lub adres IP serwera VPN, a Account to konto użytkownika służące do uwierzytelniania połączenia. W User authentication wybierz Password lub Certificate i odpowiednio podaj hasło VPN w Password albo certyfikat uwierzytelniania VPN w Certificate. Te informacje są odrębne od danych uwierzytelniających serwera proxy połączenia.
• Uruchamianie połączenia: Jeśli Connect automatically on demand jest włączone, według Sophos urządzenie aktywuje VPN, gdy aplikacja nawiązuje połączenie sieciowe. Jeśli opcja jest wyłączona, użytkownicy muszą samodzielnie włączyć VPN. Sprawdź oba przebiegi na przewidzianym urządzeniu testowym.
• Serwer proxy połączenia: Proxy udostępnia No proxy, Manually i Automatic. Przy konfiguracji ręcznej podaj prawidłowy adres serwera proxy i port w Server and port, nazwę użytkownika proxy w Authentication, a jego hasło w Password. Przy konfiguracji automatycznej wpisz w Proxy server URL adres URL serwera z ustawieniami proxy. Jest to serwer proxy tego połączenia VPN, a nie globalna konfiguracja proxy HTTP.

Dla Domains in Safari, Domains in Calendar, Domains in Contacts i Domains in Mail obowiązuje ta sama składnia: jedna domena, część domeny lub nazwa hosta w każdym wierszu. Część domeny pasuje, jeśli wszystkie składniki rozdzielone kropkami są zgodne, licząc od prawej strony; kropki na początku i na końcu są ignorowane. Ciąg bez kropki pasuje tylko do hosta o tej nazwie, a nie do dowolnych domen z takim zakończeniem. Oprócz tego obowiązuje dodatkowa reguła domeny drugiego poziomu dla kalendarza, kontaktów i poczty; odpowiedni test pozytywny opisano w sekcji dotyczącej pilotażu.

VPN dla poszczególnych aplikacji w zasadzie użytkownika iOS i przypisywanie aplikacji

Opis Sophos dotyczący Per app VPN w zasadzie użytkownika iOS dokumentuje również omówione wyżej dane wejściowe dla zainstalowanej aplikacji dostawcy VPN i jej identyfikatora w formacie odwróconej nazwy DNS, logowanie z Password lub Certificate, uruchamianie połączenia na żądanie, serwer proxy połączenia i składnię domen. Te udokumentowane cechy wspólne nie potwierdzają działającej ścieżki przypisania przy Apple User Enrollment.

Sophos dokumentuje poniższe pola dostępne pod określonymi warunkami dla Per app VPN zarówno w zasadach urządzeń iOS, jak i w zasadach użytkowników iOS. Warunki dotyczą obu typów zasad; sprawdź dostępność i obsługę dostawcy we własnym tenancie:

• W Third-party settings można wprowadzić właściwości połączenia określone przez dostawcę VPN. Pole jest dostępne tylko przy Custom SSL/TLS. Za pomocą Add wpisz potwierdzone wartości Key i Value. Te właściwości połączenia nie są Managed configuration aplikacji biznesowej, której ruch ma być tunelowany.
• Group oznacza grupę wymaganą do logowania. Pole jest dostępne tylko dla Cisco AnyConnect i Cisco Legacy AnyConnect. Nie przenoś tego warunku na inne typy połączenia.
• W Provider type opcja App proxy przenosi ruch w tunelu VPN na poziomie aplikacji, a Packet tunnel na poziomie sieci. Dla Cisco AnyConnect to ustawienie nie jest dostępne. Sprawdź na przewidzianym urządzeniu testowym, który wariant obsługuje dostawca i jaki ruch faktycznie obejmuje. Sam poziom transportu nie dowodzi izolacji aplikacji ani działania VPN na całym urządzeniu.

Przypisanie istniejącego połączenia do aplikacji biznesowej należy do procedury dystrybucji aplikacji w sekcji „Sprawdzanie konfiguracji zarządzanej i działania aplikacji”. Opisane tam przypisywanie VPN dla poszczególnych aplikacji jest wyraźnie ograniczone do istniejących zasad urządzeń iOS. Osoby odpowiedzialne za zasady udostępniają odpowiednie połączenie; osoby odpowiedzialne za aplikacje wybierają je w VPN connection used by the app. To odesłanie nie rozwiązuje opisanej wyżej niepewności dotyczącej zasad użytkowników iOS i nie dopuszcza niesprawdzonej ścieżki przypisania dla BYOD.

Sprawdź warunki wstępne, obserwuj pilotaż i diagnozuj awarie

1. Inwentaryzacja i droga powrotna: Zanotuj własność urządzenia, tryb rejestracji, nadzór, wersję iOS/iPadOS, właściwą zasadę i jej przypisanie. Dla nadzorowanego urządzenia firmowego oraz dobrowolnie udostępnionego urządzenia testowego BYOD wskaż osobno niezależną drogę dostępu do sieci (np. sieć komórkową lub inne Wi-Fi) i osobę kontaktową. Bez takiej drogi nie wdrażaj zmiany, która może odciąć łączność. Przy zmianach zasad urządzeń iOS używaj zasady testowej przypisanej wyłącznie do firmowego urządzenia pilotażowego; przed jej aktualizacją sprawdź aktualne przypisania i liczbę urządzeń docelowych. Nie modyfikuj na potrzeby pilotażu zasady przypisanej już do urządzeń produkcyjnych.
2. Zależności: Sprawdź przed zmianą i po niej osiągalność DNS, APNs/MDM, CA/SCEP/RA, serwera RADIUS/EAP, PAC/WPAD i punktu końcowego VPN. Zweryfikuj łańcuch certyfikatów, nazwy serwerów, daty wygaśnięcia i planowaną wymianę; nie kopiuj kluczy prywatnych, kodów challenge ani danych uwierzytelniających do zgłoszeń. Samo poprawne przypisanie zasady nie dowodzi działania Wi-Fi ani VPN.
3. Ograniczony pilotaż: Zacznij od oddzielnych urządzeń testowych i minimalnego przypisania. Zapisz następujące punkty jako kryteria weryfikacji, nie potwierdzone wyniki: urządzenie akceptuje zweryfikowaną tożsamość serwera RADIUS i łączy się z firmową siecią Wi-Fi. Przy logowaniu opartym na certyfikacie dodatkowo sprawdź otrzymanie certyfikatu klienta i jego akceptację przez RADIUS; przy logowaniu z nazwą użytkownika i hasłem sprawdź przewidzianą ścieżkę użycia danych uwierzytelniających. Przy VPN dla poszczególnych aplikacji sprawdź ruch przez tunel przypisanej zarządzanej aplikacji testowej; dostęp innych aplikacji wykorzystuj jako test negatywny tylko wtedy, gdy nie obejmuje ich żadne inne przypisanie VPN ani skonfigurowana reguła domenowa. Jeżeli skonfigurowano domeny dla Safari/innych przeglądarek, kalendarza, kontaktów lub poczty, sprawdź również zamierzone połączenia z pasującymi domenami i nie zakładaj ogólnie, że „pozostały ruch nie korzysta z tunelu”. Domeny Safari/przeglądarek sprawdzaj osobno: według Sophos pozytywny test dla kalendarza, kontaktów i poczty wymaga ponadto, aby domena drugiego poziomu wskazanej domeny była taka sama jak domena drugiego poziomu serwera VPN. Inna domena nie jest prawidłowym pozytywnym testem tunelu, a sam brak tunelowania takiego połączenia nie dowodzi nieudanego wdrożenia VPN. Zweryfikuj reguły domen we własnym tenancie, zamiast traktować tę wskazówkę jako niesprawdzony przepis konfiguracyjny. Osobno sprawdź na urządzeniu testowym działanie Send all traffic through VPN dla wybranego dostawcy i trybu tunelu; nie wyciągaj stąd niezweryfikowanych wniosków o działaniu na całym urządzeniu ani o izolacji aplikacji. Dla VPN dla poszczególnych aplikacji w User Policy potwierdź rzeczywiście dostępną możliwość przypisania aplikacji albo na razie wyłącz tę funkcję z zakresu. Dla PAC/WPAD obserwuj określoną ścieżkę awarii połączenia z siecią/serwerem proxy; po każdej zmianie osobno potwierdź ponowne zgłoszenie urządzenia do MDM oraz rzeczywiste działanie sieci. Jeśli urządzenie nie zgłasza się do MDM lub brakuje niezależnej drogi dostępu do sieci, zatrzymaj pilotaż i nie przypisuj kolejnych urządzeń.
4. Diagnozowanie błędu: Gdy Wi-Fi nie działa, najpierw sprawdź SSID i typ zabezpieczeń, nazwę serwera EAP oraz zaufany CA; przy logowaniu z użyciem danych uwierzytelniających sprawdź nazwę użytkownika, hasło i przewidzianą ścieżkę logowania przez RADIUS, a przy logowaniu opartym na certyfikacie — wystawioną tożsamość klienta i osiągalność CA; przy niedziałającym dostępie do stron — PAC/WPAD/DNS i uwierzytelnianie proxy; przy awarii aplikacji — aplikację dostawcy, tunel, certyfikat i przypisanie. Obserwuj status zadania/zgłoszenia do MDM i faktyczną łączność oddzielnie. Nie wywołaj kolejnej awarii przez niekontrolowane usuwanie certyfikatów lub profili.

Wycofywanie zmian bez resetowania urządzenia

Przed pilotażem przygotuj działającą zasadę zastępczą i zastępczy łańcuch zaufania oraz dostępną sieć. Usuń stare CA i certyfikaty tożsamości dopiero po potwierdzeniu działania zamienników na docelowym urządzeniu oraz zgłoszenia urządzenia do MDM.

Według Sophos zmiany w zasadach urządzeń iOS wymagają użycia Update devices: powstaje wtedy zadanie aktualizacji dla wszystkich urządzeń, do których przypisano edytowaną zasadę, a nie tylko dla urządzenia pilotażowego. Dlatego aktualizuj wyłącznie odizolowaną zasadę pilotażową, po sprawdzeniu jej aktualnych urządzeń docelowych; zadanie Assign policy skierowane do wybranych urządzeń nie jest tym samym co aktualizacja wspólnie przypisanej zasady. Zadanie docelowe Uninstall policy jest przeznaczone dla Device Enrollment, lecz może samo usunąć drogę dostępu do sieci. W przypadku zasad użytkowników iOS na urządzeniach z User Enrollment zadanie Uninstall policy nie jest dostępne: Sophos oferuje zamiast niego zadanie docelowe Unassign iOS user policy. W zależności od rodzaju awarii sensowne może być również zaktualizowanie zasady lub przypisanie innej. Nie myl zadania docelowego z operacją Unassign obejmującą wszystkie urządzenia.

iPadOS: rozróżniaj bezpośrednie akcje i typy zadań. Instrukcja obsługi zasad wyjaśnia niespójne nazewnictwo bezpośrednich ścieżek aktualizacji i odinstalowania: zestawienie typów wymienia iOS/iPadOS, a bezpośrednie instrukcje tylko iOS device policies. Nie przenoś więc ich sekwencji kliknięć na iPadOS bez weryfikacji; ustal dostępną bezpośrednią ścieżkę w tenancie i na urządzeniu pilotażowym. Nie oznacza to, że wycofanie na iPadOS jest ogólnie nieudokumentowane lub niemożliwe: typy zadań iOS/iPadOS dokumentują Uninstall policy dla Device Enrollment i Unassign iOS user policy dla User Enrollment. Procedura pakietu zadań zależna od trybu zarządzania opisuje ten wybór; nadal sprawdzaj osobno przekazanie zadania i rzeczywisty skutek wycofania.

Wycofywanie zmian sprawdź oddzielnie na osiągalnym firmowym urządzeniu testowym z Device Enrollment i osiągalnym urządzeniu testowym BYOD z User Enrollment: na urządzeniu firmowym wypróbuj właściwe zadanie docelowe Uninstall policy skierowane dokładnie do tego urządzenia, a na urządzeniu BYOD — zadanie docelowe Unassign iOS user policy. Na każdym urządzeniu potwierdź status zadania/zgłoszenia do MDM i faktycznie zsynchronizowany stan zasad; następnie ponownie przetestuj działanie Wi-Fi/VPN oraz kontakt z MDM niezależnie od siebie. Dalsze przypisania lub wycofania ogranicz do urządzeń testowych rzeczywiście poddanych weryfikacji, dopóki nie potwierdzisz obu dróg wycofania. Zapisane lub wysłane zadanie nie dotrze automatycznie do urządzenia odciętego od sieci. Potrzebna jest wcześniej zaplanowana niezależna droga dostępu do sieci i lokalny sposób usunięcia awarii; operacja Unassign obejmująca wszystkie urządzenia nie jest pozbawionym ryzyka rozwiązaniem natychmiastowym. Ani całkowite wymazanie (Wipe), ani wyrejestrowanie użytkownika nie są uniwersalnym sposobem wycofania zasady.