Dlaczego Twoja aplikacja na iPhone’a nie może włączyć ani wyłączyć systemowego VPN

Menedżer produktu prosi o przycisk, który włącza firmowy VPN, a prośba brzmi banalnie. Na iOS to nie jest mała funkcja; znajduje się poza publicznym kontraktem, a każde obejście albo nie przechodzi przeglądu, albo psuje się w kolejnym wydaniu. Przeprowadź prośbę przez to, na co platforma naprawdę pozwala, a projekt w dużej mierze napisze się sam. Aplikacja może mieć własną konfigurację VPN i ją uruchomić. Aplikacja nie może dosięgnąć systemowego przełącznika, nie może odczytać stanu profilu, którego nie utworzyła, ani utrzymać użytkownika połączonego wbrew jego woli.

Zacznij od trzech rzeczy, które użytkownik ma na myśli

Rozdziel znaczenia, zanim rozdzielisz API. Czasem użytkownik chce, aby tunel Twojej aplikacji był połączony, czasem chce przełączyć przełącznik w Ustawieniach dla profilu zainstalowanego przez kogoś innego, a czasem chce, aby telefon nie mógł przeglądać bez tunelu. Odpowiada to trzem różnym mechanizmom, a tylko pierwszy jest otwarty dla zwykłej aplikacji.

Drugie znaczenie to to, które rodzi pytania na Stack Overflow, i nie ma na nie wspieranej odpowiedzi. Przełącznik w Ustawieniach należy do użytkownika, a na urządzeniach zarządzanych do profilu. Żadne publiczne API nie wylicza konfiguracji VPN, nie raportuje, czy tunel systemowy jest podniesiony, ani go nie przełącza.

Co aplikacja naprawdę może utworzyć

NetworkExtension daje aplikacji własną konfigurację przez NEVPNManager. Z uprawnieniem Personal VPN i zgodą użytkownika aplikacja zapisuje konfigurację, która pojawia się w Ustawieniach pod jej nazwą, i może uruchomić lub zatrzymać to jedno połączenie. To realna, poddająca się przeglądowi możliwość, i to zarazem cały zakres: menedżer czyta i zapisuje tylko to, co sam utworzył.

Uprawnienie nie jest automatyczne. Prosisz o nie Apple’a i uzasadniasz, dlaczego aplikacja w ogóle potrzebuje tunelu, a klient, którego jedynym celem jest włączenie cudzego profilu, nie ma dobrej odpowiedzi. Dostawcy tuneli pakietowych stosują tę samą zasadę z inną klasą: NETunnelProviderManager posiada konfiguracje oparte na dostawcy, które sama aplikacja zainstalowała. Żadna z dróg nie dociera do profilu dostarczonego przez MDM.

Zgoda obowiązuje także przy zapisie. Zapis konfiguracji pyta użytkownika, a tego pytania aplikacja nie może wyciszyć dla wygody.

Odczyt stanu trafia na tę samą ścianę

Stan wygląda przyjaźniej niż sterowanie i jest równie zamknięty. NEVPNStatus zgłasza nieprawidłowy, rozłączony, łączenie, połączony, ponowne potwierdzanie lub rozłączanie dla własnej konfiguracji aplikacji, a przy każdej zmianie uruchamia się powiadomienie. Nie mówi nic o tunelu zainstalowanym przez profil zarządzania, a właśnie ten stan chce widzieć pomoc techniczna.

Monitorowanie ścieżki sieciowej i zmiany interfejsu są oferowane jako zamienniki w przeglądach projektowych. Opisują ścieżkę ruchu aplikacji, która zmienia się z powodów niezwiązanych ze stanem VPN, a używanie ich jako odczytu VPN daje interfejs, który kłamie w obie strony.

On Demand i Always On to prawdziwe dźwignie

Wspierane dźwignie żyją w profilu, a nie w aplikacji. Reguły On Demand mówią systemowi, kiedy się połączyć: uporządkowana lista warunków z działaniami, oceniana przez system operacyjny, a nie przez Twój kod. Reguła, która łączy się w dowolnym interfejsie, tworzy poczucie stałego połączenia, nie dając aplikacji żadnej kontroli.

Always On VPN to mechanizm egzekwowania i jest powiązany z nadzorem. Na urządzeniu nadzorowanym MDM instaluje profil, który utrzymuje tunel, a na prywatnym telefonie bez nadzoru te same klucze nie dają takiego samego zachowania. Ta asymetria jest zamierzona i żadna kombinacja kluczy ładunku jej nie usuwa. Gdy wymaganiem jest naprawdę to, że VPN musi być włączony, wymaganiem jest w istocie to, że urządzeniem trzeba zarządzać.

Pomiędzy nimi siedzi słabszy kuzyn: reguła, która łączy ponownie po rozłączeniu przez użytkownika. Łączy się, gdy reguła zostanie oceniona następnym razem, co nie jest tym samym co natychmiast, a użytkownik, który rozłączył się celowo, zauważy różnicę. Projektuj interfejs wokół tej luki, zamiast obiecywać kłódkę.

Dostarcz wspieraną ścieżkę

Cztery pytania rozstrzygają mechanizm, zanim powstanie jakikolwiek kod: kto jest właścicielem urządzenia, czy jest nadzorowane, który klient kończy tunel i skąd pochodzi profil. Jeśli cokolwiek z tego jest nieznane, prośba o funkcję nie jest gotowa do oszacowania.

Prywatne API, które dłubie w systemowym VPN, przejdzie demo i obleje przegląd, a jeśli zostanie dostarczone inną drogą, zepsuje się w kolejnym wydaniu iOS. Nie ma wersji tej wymiany, która byłaby warta jednego przełącznika.

Telemetria zarządzania to osobny kanał: raportuje, że profil jest zainstalowany i czy urządzenie jest zgodne, co jest raportowaniem, a nie powierzchnią sterowania dla aplikacji. Testuj przepływ na prawdziwym urządzeniu po każdej aktualizacji, bo wspierane zachowanie żyje w systemie operacyjnym, a system operacyjny się porusza.