Po-aplika VPN en administrataj iPhone-aplikaĵoj: kio estas enkursigita kaj kio ne
Po-aplika tunelo sekvas la administrataĵon, ne la telefonon. Kontrolu la ligon de la profilo, la administrata kopio, la regulojn laŭ postulo kaj la fluojn, kiuj forlasas la aplikaĵon.
Po-aplika VPN en iPhone ne estas ŝaltilo por la tuta telefono. Ĝi estas ligo inter unu administrata aplikaĵo kaj unu VPN-profilo, kreita kiam la aplikaĵo estas disvastigita, kaj la trafiko de ĉio alia konservas la itineron, kiun ĝi havis antaŭe. Tial la sama telefono kondutas sin malkonsekvence: la laboreja aplikaĵo malfermas privatan paĝon dum Safari ne atingas la saman gastiganton, aŭ la tunelo tute ne leviĝas kaj la aplikaĵo raportas tempolimon, kiu aspektas kiel malbonaj akreditaĵoj. La kontroloj iras de la plej larĝa kaŭzo malsupren, do haltu ĉe la unua, kiu malsukcesas.
Unue kontrolu la profilon kaj la rikordon de la aplikaĵo
La ligo vivas en du objektoj, ne en unu. La VPN-profilo difinas la tunelon: tipo, servilo, aŭtentikigo, DNS kaj la pakaĵa identigilo de la provizanto, kiam oni uzas propran klienton. La rikordo de la aplikaĵo montras al tiu profilo, kaj plej multaj administradaj konzoloj proponas tion kiel po-aplikan opcion en la agordo de la aplikaĵo, kun nomo proksima al Per-App VPN. Profilo, al kiu neniu aplikaĵo montras, enkursigas nenion po aplikaĵo; ĝi kondutas sin kiel ordinara tunelo, kiun iu devas mane startigi.
Legu ambaŭ objektojn antaŭ ol tuŝi la telefonon. Konfirmu, ke la agordo de la aplikaĵo referencas la profilon, kiun vi testas, kaj ne pli malnovan kopion, ĉar duoblaj profiloj kun preskaŭ identaj nomoj oftas post migrado kaj la aplikaĵo volonte montras al la retiriĝinta. Poste konfirmu, ke la agordo atingis la aparaton: Agordoj, Ĝeneralaj, VPN kaj Administrado de Aparato devas montri ĝin kiel instalitan profilon. La VPN-listo tie ne estas la testo. Po-aplika servo kutime ne havas manan ŝaltilon, do ĝuste disvastigita agordo eble neniam aperos inter la startigeblaj VPN-oj. La manko vidiĝas en la rikordo de la aplikaĵo kaj en tio, ĉu la tunelo leviĝas ĉe la unua peto de la aplikaĵo.
Unu kondiĉo klarigas multajn biletojn: ĉi tiu modelo bezonas, ke la aplikaĵo alvenu per administrado. Flanke instalita aŭ persone aĉetita kopio ne ricevas la ligon, eĉ kiam ĝia pakaĵa identigilo kongruas. La disvastiga gvidilo de Apple pri VPN priskribas la profilan modelon malantaŭ tio (support.apple.com/guide/deployment/vpn-overview-depae3d361d0/web).
Konfirmu, ke la instalita aplikaĵo estas la administrata kopio
La ligo sekvas la instalitan, administrataĵon. Se iu reinstalis ĝin el App Store sub persona Apple ID, anstataŭigis ĝin per re-subskribita entreprena versio, aŭ la aparato estis re-enregistrita kaj la aplikaĵo revenis per alia kanalo, la tunelo povas resti malsupre dum la aplikaĵo mem aspektas tute normale.
Testu per komparo, ne per unu observo. En la administrada inventaro la aplikaĵo devas aperi kiel administrata por tiu aparato kun la VPN-mapo en sia rikordo. Sur la telefono la tunelo devas leviĝi kiam la aplikaĵo lanĉiĝas kaj ĝia unua peto eliras, ne nur kiam iu startigas apartan manan agordon en Agordoj. Se lanĉi la aplikaĵon ŝanĝas nenion kaj tiu mana agordo ŝanĝas, la aplikaĵo tute ne estas ligita al po-aplika tunelo.
Ĝisdatigoj gravas: tiu sendita per administrado konservas la mapon, dum uzanto-iniciatita reinstalo povas perdi ĝin. Kiam la plendo datiĝas de ĝisdatigo, kontrolu la rikordon de la aplikaĵo antaŭ la reto.
Kontrolu, kion la tunelo rajtas preni
Po-aplika tunelo elektiĝas laŭ la fonta aplikaĵo, do la defaŭlta itinero de la telefono ankoraŭ apartenas al Wi-Fi aŭ poŝtelefona reto. OverridePrimary estas la ŝlosilo, kiu tion ŝanĝas. Kiam profilo ĝin agordas, la tunelo kondutas sin kiel plena tunelo kaj ĉiu aplikaĵo heredas ĝin, do ĉio tra la VPN fariĝas demanda pri profilo anstataŭ aplikaĵa fiasko.
La reguloj laŭ postulo decidas pri persisteco. OnDemandEnabled kun sia regularo igas la tunelon reveni kiam la aplikaĵo sendas trafikon, postvivi ŝanĝon de Wi-Fi al poŝtelefona reto, aŭ fali kiam la aplikaĵo iras al la fono. Disvastigo, kiu konektiĝas kaj poste silente mortas, kutime havas regulon kongruan nur kun sondilo, kiu neniam ekfunkcias dum la aplikaĵo estas senaga.
Poste legu la itineran flankon honeste. Se provizanta aŭ vendista profilo liveras inkluzivan liston, tunelo portanta nur 10.20.0.0/16 ne portos servon en 10.30.0.0/16; tio estas la listo faranta sian taskon, ne po-aplika fiasko. La enkonstruita iOS-profilo havas neniun inkluzivan liston. Sen ĝi la divido sekvas la provizantajn defaŭltojn kaj IncludeAllNetworks, ne kaŝitan liston.
Testu la aplikaĵon, poste testu, kio eliras el ĝi
Testu per nomo, ne nur per adreso. Solvi internan gastiganton ene de la administrata aplikaĵo pruvas, ke ankaŭ DNS iris tra la tunelo, ĉar la profilo decidas, kiu solvilo respondas kaj kiuj serĉaj domejnoj aplikiĝas. Enkursigado povas esti perfekta dum nomoserĉo malsukcesas, kaj la du simptomoj montras al malsamaj agordoj.
Poste testu la limon de ambaŭ flankoj. Persona aplikaĵo aŭ Safari devus atingi ordinaran publikan paĝon kaj raporti la operatoran aŭ hejman adreson, dum la administrata aplikaĵo atingas la privatan servon. Se ambaŭ raportas la saman publikan adreson, la tunelo jam ne estas po-aplika, kion ajn asertas la rikordo de la aplikaĵo.
La fluoj, kiuj forlasas la aplikaĵon, kreas la konfuzajn biletojn. Ligo, kiu malfermiĝas en Safari, dokumento transdonita per la divida folio, aŭ SSO-ensaluto, kiu transiras al retumilo, forlasas la procezon de la aplikaĵo kaj la tunelon kun ĝi. Ensaluto montrata ene de la aplikaĵo kutime atribuiĝas al la aplikaĵo, do enkonstruita ensaluto povas sukcesi tie, kie la sama URL malsukcesas en Safari; kontrolu tion anstataŭ supozi. Kiam la identeca provizanto atingeblas nur tra la tunelo, aŭ tenu la ensaluton ene de la aplikaĵo aŭ aldonu la provizantan domejon al la Safari-domejnoj de la profilo, por ke kongrua Safari-trafiko estu kaptita.
Parigu la simptomon kun la tavolo
La formo de la fiasko diras al vi, kiun kontrolon ripeti.
| 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 |
Malantaŭ la mezaj vicoj staras du detaloj: po-aplika tunelo povas esti sana kaj tamen maltrafi subreton, kiun neniu provizanta listo inkluzivas, kaj administrata telefono povas teni pli ol unu VPN-agordon, do konfirmu, al kiu la aplikaĵo estas ligita, anstataŭ supozi, ke ĝi estas tiu, kiun vi legas.
Riparu en ĉi tiu ordo: korektu la rikordon de la aplikaĵo por ke ĝi referencu la vivan profilon, reinstalu la aplikaĵon per administrado, konfirmu, ke la tunelo leviĝas ĉe la unua peto de la aplikaĵo, poste ripetu la nomajn kaj limajn testojn. Se la unua peto tute ne povas startigi tunelon, haltu kaj kontrolu la provizantan flankon, ĉar propra kliento bezonas sian Network Extension ĉeesta kun identigilo kongrua al la instalita aplikaĵo.
Redonu tri faktojn anstataŭ ekrankopio: al kiu profilo referencas la rikordo de la aplikaĵo, ĉu Agordoj montras ĝin kiel instalitan profilon, kaj kio estis la malsukcesinta peto, nomo, adreso aŭ transigo al retumilo. Tiuj tri respondoj apartigas disvastigan eraron de enkursigada eraro, kaj la sekva persono povas agi sen ripeti la diagnozon.