VPN na aplikację na zarządzanych iPhone'ach: co jest kierowane, a co nie
Tunel na aplikację podąża za zarządzaną aplikacją, a nie telefonem. Sprawdź powiązanie ładunku, zarządzaną kopię, reguły na żądanie i przepływy wychodzące z aplikacji.
VPN na aplikację na iPhone nie jest przełącznikiem całego telefonu. To powiązanie jednej zarządzanej aplikacji z jednym ładunkiem VPN, tworzone przy wdrażaniu aplikacji, a ruch całej reszty zachowuje dotychczasową trasę. Dlatego ten sam telefon zachowuje się niespójnie: aplikacja służbowa otwiera prywatną stronę, a Safari nie dociera do tego samego hosta, albo tunel w ogóle nie wstaje i aplikacja zgłasza przekroczenie limitu czasu, które wygląda jak błędne dane logowania. Kontrole idą od najszerszej przyczyny w dół, więc zatrzymaj się na pierwszej, która zawiedzie.
Najpierw sprawdź ładunek i rekord aplikacji
Powiązanie żyje w dwóch obiektach, nie w jednym. Ładunek VPN definiuje tunel: typ, serwer, uwierzytelnianie, DNS i identyfikator pakietu dostawcy, gdy używany jest klient niestandardowy. Rekord aplikacji wskazuje na ten ładunek, a większość konsol zarządzania oferuje to jako opcję na aplikację w konfiguracji aplikacji, pod nazwą bliską Per-App VPN. Ładunek, na który nie wskazuje żadna aplikacja, nie kieruje niczego na aplikację; zachowuje się jak zwykły tunel, który ktoś musi uruchomić ręcznie.
Przeczytaj oba obiekty, zanim dotkniesz telefonu. Potwierdź, że konfiguracja aplikacji wskazuje na testowany ładunek, a nie na jego starszą kopię, bo zduplikowane ładunki o niemal identycznych nazwach są częste po migracji, a aplikacja chętnie wskazuje na wycofany. Potem potwierdź, że konfiguracja dotarła do urządzenia: Ustawienia, Ogólne, VPN i zarządzanie urządzeniem muszą pokazywać ją jako zainstalowany profil. Lista VPN tam nie jest testem. Usługa na aplikację zwykle nie ma ręcznego przełącznika, więc poprawnie wdrożona konfiguracja może nigdy nie pojawić się wśród VPN-ów, które można uruchomić. Brak widać w rekordzie aplikacji i w tym, czy tunel wstaje przy pierwszym żądaniu aplikacji.
Jeden warunek wyjaśnia wiele zgłoszeń: ten model wymaga, aby aplikacja przyszła przez zarządzanie. Kopia zainstalowana z boku lub kupiona prywatnie nie dostaje powiązania, nawet gdy jej identyfikator pakietu się zgadza. Przewodnik Apple dotyczący wdrażania VPN opisuje model ładunku, który za tym stoi (support.apple.com/guide/deployment/vpn-overview-depae3d361d0/web).
Potwierdź, że zainstalowana aplikacja jest zarządzaną kopią
Powiązanie podąża za zainstalowaną, zarządzaną aplikacją. Jeśli ktoś zainstalował ją ponownie z App Store na prywatny Apple ID, zastąpił ją ponownie podpisaną kompilacją firmową albo urządzenie zostało ponownie zarejestrowane i aplikacja wróciła innym kanałem, tunel może pozostać w dole, podczas gdy sama aplikacja wygląda całkowicie normalnie.
Testuj przez porównanie, nie jednym spostrzeżeniem. W inwentarzu zarządzania aplikacja musi być widoczna jako zarządzana dla tego urządzenia, z mapowaniem VPN w swoim rekordzie. Na telefonie tunel ma wstać przy uruchomieniu aplikacji i wyjściu jej pierwszego żądania, nie tylko wtedy, gdy ktoś w Ustawieniach uruchomi osobną konfigurację ręczną. Jeśli uruchomienie aplikacji nic nie zmienia, a ta ręczna konfiguracja zmienia, aplikacja wcale nie jest związana z tunelem na aplikację.
Aktualizacje się liczą: wypchnięta przez zarządzanie zachowuje mapowanie, a ponowna instalacja uruchomiona przez użytkownika może je utracić. Gdy zgłoszenie datuje się od aktualizacji, sprawdź rekord aplikacji przed siecią.
Sprawdź, co tunel może przejąć
Tunel na aplikację jest wybierany przez aplikację źródłową, więc domyślna trasa telefonu nadal należy do Wi-Fi lub sieci komórkowej. OverridePrimary to klucz, który to zmienia. Gdy profil go ustawia, tunel zachowuje się jak pełny tunel i każda aplikacja go dziedziczy, więc wszystko, co przechodzi przez VPN, staje się kwestią profilu, a nie awarią aplikacji.
Reguły na żądanie decydują o trwałości. OnDemandEnabled i jego zestaw reguł przywracają tunel, gdy aplikacja wysyła ruch, przetrzymują przejście z Wi-Fi do sieci komórkowej lub opuszczają go, gdy aplikacja schodzi do tła. Wdrożenie, które łączy się i potem cicho umiera, zwykle ma regułę pasującą tylko do sondy, która nigdy nie rusza, gdy aplikacja jest bezczynna.
Potem przeczytaj stronę tras uczciwie. Jeśli profil dostawcy lub sprzedawcy podaje listę dołączeń, tunel niosący tylko 10.20.0.0/16 nie będzie niósł usługi w 10.30.0.0/16; to lista wykonuje swoją pracę, a nie awaria na aplikację. Wbudowany ładunek iOS nie ma listy dołączeń. Bez niej podział idzie za domyślnymi ustawieniami dostawcy i IncludeAllNetworks, a nie ukrytą listą.
Przetestuj aplikację, a potem to, co z niej wychodzi
Testuj po nazwie, nie tylko po adresie. Rozwiązanie wewnętrznego hosta w zarządzanej aplikacji dowodzi, że DNS też przeszedł przez tunel, bo ładunek decyduje, który resolver odpowie i które domeny wyszukiwania obowiązują. Routing może być doskonały, gdy wyszukiwanie nazwy zawodzi, a oba objawy wskazują na różne ustawienia.
Potem przetestuj granicę z obu stron. Prywatna aplikacja lub Safari powinny dotrzeć do zwykłej publicznej strony i zgłosić adres operatora lub domowy, a zarządzana aplikacja dociera do usługi prywatnej. Jeśli obie zgłaszają ten sam publiczny adres, tunel nie jest już na aplikację, cokolwiek twierdzi rekord aplikacji.
Przepływy wychodzące z aplikacji tworzą mylące zgłoszenia. Link otwierany w Safari, dokument przekazany przez arkusz udostępniania albo logowanie SSO przechodzące do przeglądarki opuszczają proces aplikacji i razem z nim tunel. Logowanie pokazywane w aplikacji jest zwykle przypisywane aplikacji, więc logowanie wbudowane może się udać tam, gdzie ten sam URL zawodzi w Safari; zweryfikuj to, zamiast zakładać. Gdy dostawca tożsamości jest osiągalny tylko przez tunel, trzymaj logowanie w aplikacji albo dodaj domenę dostawcy do domen Safari ładunku, aby pasujący ruch Safari został przechwycony.
Dopasuj objaw do warstwy
Kształt awarii mówi, którą kontrolę powtórzyć.
| What you see | Where the repair is |
|---|---|
| Tunnel never appears when the app opens | App-to-payload association, or the app is not the managed copy |
| Tunnel connects, internal name resolves, connection times out | Provider or vendor include list missing the subnet, or a far-side firewall |
| Tunnel connects, internal name fails to resolve | DNS servers or search domains in the payload |
| Every app uses the tunnel | OverridePrimary set, or a full-tunnel payload reused |
| Worked until an update, broken since | Association lost on reinstall, or the payload was replaced |
Za środkowymi wierszami stoją dwa szczegóły: tunel na aplikację może być zdrowy i mimo to pominąć podsieć, której nie ma na żadnej liście dostawcy, a zarządzany telefon może trzymać więcej niż jedną konfigurację VPN, więc potwierdź, do której aplikacja jest przypisana, zamiast zakładać, że to ta, którą czytasz.
Napraw w tej kolejności: popraw rekord aplikacji, aby wskazywał aktywny ładunek, zainstaluj aplikację ponownie przez zarządzanie, potwierdź, że tunel wstaje przy pierwszym żądaniu aplikacji, a potem powtórz testy nazwy i granicy. Jeśli pierwsze żądanie w ogóle nie może uruchomić tunelu, zatrzymaj się i sprawdź stronę dostawcy, bo klient niestandardowy potrzebuje istniejącego Network Extension i identyfikatora zgodnego z zainstalowaną aplikacją.
Zwróć trzy fakty zamiast zrzutu ekranu: na który ładunek wskazuje rekord aplikacji, czy Ustawienia pokazują go jako zainstalowany profil i jakie było nieudane żądanie — nazwa, adres czy przekazanie do przeglądarki. Te trzy odpowiedzi oddzielają błąd wdrożenia od błędu routingu, a następna osoba może działać bez powtarzania diagnozy.