VPN pēc lietotnes pārvaldītās iPhone lietotnēs: kas tiek maršrutēts un kas ne
Lietotnes līmeņa tunelis seko pārvaldītajai lietotnei, nevis tālrunim. Pārbaudiet lietderīgās kravas saistību, pārvaldīto kopiju, pieprasījuma noteikumus un plūsmas, kas iziet no lietotnes.
VPN pēc lietotnes iPhone nav visa tālruņa slēdzis. Tā ir saistība starp vienu pārvaldītu lietotni un vienu VPN lietderīgo kravu, kas tiek izveidota, izvietojot lietotni, un visa pārējā trafiks saglabā iepriekšējo maršrutu. Tāpēc tas pats tālrunis uzvedas nekonsekventi: darba lietotne atver privātu lapu, kamēr Safari nesasniedz to pašu resursdatoru, vai tunelis vispār neceļas un lietotne ziņo par taimautu, kas izskatās kā nepareizi akreditācijas dati. Pārbaudes iet no visplašākā iemesla uz leju, tāpēc apstājieties pie pirmās neveiksmes.
Vispirms pārbaudiet lietderīgo kravu un lietotnes ierakstu
Saistība dzīvo divos objektos, nevis vienā. VPN lietderīgā krava definē tuneli: tipu, serveri, autentifikāciju, DNS un pakalpojumu sniedzēja komplekta identifikatoru, ja izmanto pielāgotu klientu. Lietotnes ieraksts norāda uz šo kravu, un lielākā daļa pārvaldības konsoļu to piedāvā kā opciju pēc lietotnes lietotnes konfigurācijā ar nosaukumu, kas tuvs Per-App VPN. Krava, uz kuru nenorāda neviena lietotne, pēc lietotnes neko nemaršrutē; tā uzvedas kā parasts tunelis, kas kādam jāpalaiž manuāli.
Izlasiet abus objektus pirms tālruņa aiztikšanas. Pārliecinieties, ka lietotnes konfigurācija norāda uz testējamo kravu, nevis tās veco kopiju, jo pēc migrācijas dubultas kravas ar gandrīz vienādiem nosaukumiem ir ierastas un lietotne labprāt norāda uz atsaukto. Pēc tam pārliecinieties, ka konfigurācija ir sasniegusi ierīci: Iestatījumi, Vispārīgi, VPN un ierīces pārvaldība tai jārāda kā instalēts profils. Tur esošais VPN saraksts nav tests. Pakalpojumam pēc lietotnes parasti nav manuāla slēdža, tāpēc pareizi izvietota konfigurācija var nekad neparādīties starp palaižamajiem VPN. Neesamība redzama lietotnes ierakstā un tajā, vai tunelis paceļas lietotnes pirmajā pieprasījumā.
Viens nosacījums izskaidro daudzus biļetes: šim modelim lietotnei jānāk caur pārvaldību. Blakus instalēta vai personīgi iegādāta kopija saistību nesaņem, pat ja tās komplekta identifikators sakrīt. Apple VPN izvietošanas rokasgrāmata apraksta aiz tā esošo kravas modeli (support.apple.com/guide/deployment/vpn-overview-depae3d361d0/web).
Pārliecinieties, ka instalētā lietotne ir pārvaldītā kopija
Saistība seko instalētajai pārvaldītajai lietotnei. Ja kāds to pārinstalēja no App Store ar personīgu Apple ID, nomainīja ar no jauna parakstītu uzņēmuma būvējumu vai ierīce tika reģistrēta no jauna un lietotne atgriezās pa citu kanālu, tunelis var palikt lejā, kamēr pati lietotne izskatās pilnīgi normāli.
Testējiet salīdzinot, nevis ar vienu novērojumu. Pārvaldības inventārā lietotnei jārādās kā pārvaldīta šai ierīcei ar VPN kartējumu tās ierakstā. Tālrunī tunelim jāpaceļas, kad lietotne tiek palaista un iziet tās pirmais pieprasījums, nevis tikai tad, kad kāds Iestatījumos palaiž atsevišķu manuālu konfigurāciju. Ja lietotnes palaišana neko nemaina, bet šī manuālā konfigurācija maina, lietotne vispār nav saistīta ar tuneli pēc lietotnes.
Atjauninājumi ir svarīgi: caur pārvaldību nosūtītais saglabā kartējumu, savukārt lietotāja sākta pārinstalēšana var to pazaudēt. Ja sūdzība datēta no atjauninājuma, pirms tīkla pārbaudiet lietotnes ierakstu.
Pārbaudiet, ko tunelis drīkst paņemt
Tunelis pēc lietotnes tiek izvēlēts pēc avota lietotnes, tāpēc tālruņa noklusējuma maršruts joprojām pieder Wi-Fi vai mobilajam tīklam. OverridePrimary ir atslēga, kas to maina. Kad profils to iestata, tunelis uzvedas kā pilns tunelis un katra lietotne to manto, tāpēc viss, kas iet caur VPN, kļūst par profila, nevis lietotnes kļūmes jautājumu.
Pieprasījuma noteikumi nosaka noturību. OnDemandEnabled un tā noteikumu kopa atgriež tuneli, kad lietotne sūta trafiku, pārdzīvo pāreju no Wi-Fi uz mobilo tīklu vai nolaiž to, kad lietotne aiziet fonā. Izvietojumam, kas pieslēdzas un pēc tam klusi mirst, parasti ir noteikums, kas atbilst tikai zondējumam, kurš nekad neiedarbojas, kamēr lietotne ir neaktīva.
Pēc tam godīgi izlasiet maršrutu pusi. Ja pakalpojumu sniedzēja vai pārdevēja profils sniedz iekļaušanas sarakstu, tunelis, kas nes tikai 10.20.0.0/16, nesīs pakalpojumu 10.30.0.0/16; tas ir saraksts, kas dara savu darbu, nevis kļūme pēc lietotnes. Iebūvētajam iOS profilam nav iekļaušanas saraksta. Bez tā sadalījums seko pakalpojumu sniedzēja noklusējumiem un IncludeAllNetworks, nevis slēptam sarakstam.
Pārbaudiet lietotni, pēc tam to, kas no tās iziet
Pārbaudiet pēc nosaukuma, ne tikai pēc adreses. Iekšējā resursdatora atrisināšana pārvaldītajā lietotnē pierāda, ka arī DNS gāja caur tuneli, jo krava nosaka, kurš atrisinātājs atbildēs un kuri meklēšanas domēni tiks piemēroti. Maršrutēšana var būt nevainojama, kamēr nosaukuma meklēšana neizdodas, un abi simptomi norāda uz dažādiem iestatījumiem.
Pēc tam pārbaudiet robežu no abām pusēm. Personīgai lietotnei vai Safari jāsasniedz parasta publiska lapa un jāziņo operatora vai mājas adrese, kamēr pārvaldītā lietotne sasniedz privāto pakalpojumu. Ja abas ziņo vienu un to pašu publisko adresi, tunelis vairs nav pēc lietotnes, lai ko apgalvotu lietotnes ieraksts.
Plūsmas, kas iziet no lietotnes, rada mulsinošas biļetes. Saite, kas atveras Safari, dokumenti, kas nodoti caur koplietošanas lapu, vai SSO pieteikšanās, kas pāriet uz pārlūku, pamet lietotnes procesu un kopā ar to arī tuneli. Lietotnē parādītā pieteikšanās parasti tiek attiecināta uz lietotni, tāpēc iegultā pieteikšanās var izdoties tur, kur tā pati URL neizdodas Safari; pārbaudiet to, nevis pieņemiet. Ja identitātes pakalpojumu sniedzējs ir sasniedzams tikai caur tuneli, turiet pieteikšanos lietotnē vai pievienojiet sniedzēja domēnu kravas Safari domēniem, lai atbilstošais Safari trafiks tiktu uztverts.
Saskaņojiet simptomu ar slāni
Kļūmes forma pasaka, kura pārbaude jāatkārto.
| 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 |
Aiz vidējām rindām ir divas detaļas: tunelis pēc lietotnes var būt vesels un tomēr palaist garām apakštīklu, ko neietver neviens sniedzēja saraksts, un pārvaldīts tālrunis var turēt vairāk nekā vienu VPN konfigurāciju, tāpēc pārliecinieties, kurai lietotne ir piesaistīta, nevis pieņemiet, ka tā ir tā, kuru lasāt.
Labojiet šādā secībā: izlabojiet lietotnes ierakstu, lai tas norādītu uz aktīvo kravu, pārinstalējiet lietotni caur pārvaldību, pārliecinieties, ka tunelis paceļas lietotnes pirmajā pieprasījumā, tad atkārtojiet nosaukuma un robežas testus. Ja pirmais pieprasījums vispār nevar palaist tuneli, apstājieties un pārbaudiet sniedzēja pusi, jo pielāgotam klientam ir vajadzīgs esošs Network Extension un identifikators, kas atbilst instalētajai lietotnei.
Atgrieziet trīs faktus, nevis ekrānuzņēmumu: uz kuru kravu norāda lietotnes ieraksts, vai Iestatījumi to rāda kā instalētu profilu un kāds bija neveiksmīgais pieprasījums — nosaukums, adrese vai pāreja uz pārlūku. Šīs trīs atbildes atšķir izvietošanas kļūdu no maršrutēšanas kļūdas, un nākamā persona var rīkoties, neatkārtojot diagnostiku.