Per-app VPN op behearde iPhone-apps: wat wol rûte wurde en wat net
In per-app-tunnel folget de behearder app, net de telefoan. Kontrolearje de payload-bining, de behearde kopy, on-demand-regels en de streams dy't de app ferlitte.
Per-app VPN op iPhone is gjin skeakel foar de hiele telefoan. It is in bining tusken ien behearder app en ien VPN-payload, makke by it útrollen fan de app, en ferkear fan al it oare hâldt de rûte dy't it earder hie. Dêrom hâldt deselde telefoan him inkonsekwint: de wurkapp iepenet in priveeside wylst Safari deselde host net berikke kin, of de tunnel komt hielendal net omheech en de app meldt in time-out dy't op minne oanmeldgegevens liket. De kontrôles geane fan de breedste oarsaak nei ûnderen, dus stopje by de earste dy't mislearret.
Kontrolearje earst de payload en de app-registraasje
De bining libbet yn twa objekten, net yn ien. De VPN-payload definiearret de tunnel: type, server, autentikaasje, DNS en de bundle-identifikaasje fan de provider as in oanpaste klant brûkt wurdt. De app-registraasje wiist nei dy payload, en de measte behear-konsoles biede dat as per-app-opsje oan yn 'e app-konfiguraasje, mei in namme tichtby Per-App VPN. In payload dêr't gjin app nei wiist, rûtet neat per app; it hâldt him as in gewoane tunnel dy't immen mei de hân starte moat.
Lês beide objekten foardat jo de telefoan oanreitsje. Befêstigje dat de app-konfiguraasje nei de payload wiist dy't jo testen en net nei in âldere kopy, want dûele payloads mei hast deselde nammen binne gewoan nei in migraasje en de app wiist graach nei de ôftanke. Befêstigje dan dat de konfiguraasje it apparaat berikt hat: Ynstellings, Algemien, VPN en apparaatbehear moatte it as ynstallearre profyl sjen litte. De VPN-list dêre is de test net. In per-app-tsjinst hat meast gjin hânskeakel, dus in korrekt útrole konfiguraasje ferskynt miskien nea tusken de VPN's dy't jo starte kinne. De ôfwêzigens is te sjen yn 'e app-registraasje en yn oft de tunnel by it earste fersyk fan de app omheech komt.
Ien betingst ferklearret in soad tickets: dit model freget dat de app fia behear binnenkomt. In side-laden of persoanlik kochte kopy krijt de bining net, sels as de bundle-identifikaasje oerienkomt. De útrôlguide fan Apple foar VPN beskriuwt it payload-model dêr't dit efter sit (support.apple.com/guide/deployment/vpn-overview-depae3d361d0/web).
Befêstigje dat de ynstallearre app de behearde kopy is
De bining folget de ynstallearre, behearde app. As immen dy op 'e nij ynstallearre hat út 'e App Store mei in persoanlik Apple ID, ferfongen hat troch in op 'e nij ûndertekene enterprise-build, of it apparaat op 'e nij ynskreaun is en de app fia in oar kanaal weromkaam, kin de tunnel omleech bliuwe wylst de app sels folslein normaal liket.
Test troch fergeliking, net troch ien waarnimming. Yn 'e behearynventaris moat de app foar dat apparaat as beheard stean mei de VPN-mapping yn 'e registraasje. Op 'e telefoan moat de tunnel omheech komme as de app start en syn earste fersyk útegiet, net allinne as immen in aparte hânkonfiguraasje yn Ynstellings startet. As it starten fan 'e app neat feroaret en dy hânkonfiguraasje wol, is de app hielendal net oan in per-app-tunnel bûn.
Fernijingen binne wichtich: ien dy't fia behear trochstjoerd wurdt hâldt de mapping, wylst in troch de brûker starte werynstallaasje dy ferlieze kin. As de klacht fan in fernijing datearret, kontrolearje dan de app-registraasje foar it netwurk.
Kontrolearje wat de tunnel nimme mei
In per-app-tunnel wurdt keazen troch de boarne-app, dus de standertrûte fan 'e telefoan heart noch altyd by Wi-Fi of mobyl. OverridePrimary is de kaai dy't dat feroaret. As in profyl dy set, hâldt de tunnel him as in folsleine tunnel en elke app erft dy, sadat alles fia de VPN in profylkwestje wurdt ynstee fan in app-flater.
On-demand-regels beslisse oer it oanhâlden. OnDemandEnabled plus syn regelset soarget derfoar dat de tunnel weromkomt as de app ferkear stjoert, in oergong fan Wi-Fi nei mobyl oerlibbet, of sakket as de app nei de eftergrûn giet. In útrôle dy't ferbynt en dan stil stjert hat meast in regel dy't allinne past by in probe dy't nea ôfgiet wylst de app stil sit.
Lês dan de rûtekant earlik. As in provider- of ferkeaperprofyl in ynslúty list leveret, sil in tunnel dy't allinne 10.20.0.0/16 draacht gjin tsjinst yn 10.30.0.0/16 drage; dat is de list dy't syn wurk docht, gjin per-app-flater. De ynboude iOS-payload hat gjin ynslúty list. Sûnder ien folget de splitsing de provider-standerts en IncludeAllNetworks, net in ferburgen list.
Test de app, test dan wat derút giet
Test mei in namme, net allinne mei in adres. It oplossen fan in ynterne host binnen de behearder app bewissiget dat DNS ek troch de tunnel gie, want de payload beslisset hokker resolver antwurdet en hokker sykdominen tapast wurde. Rûte kin perfekt wêze wylst namme-opfreegjen mislearret, en de twa symptomen wize op ferskillende ynstellings.
Test dan de grins fan beide kanten. In persoanlike app of Safari moat in gewoane iepenbiere side berikke en it adres fan de provider of thús melde, wylst de behearder app de privee tsjinst berikt. As beide itselde iepenbiere adres melde, is de tunnel net mear per app, wat de app-registraasje ek beweart.
Streams dy't de app ferlitte meitsje de betize tickets. In keppeling dy't yn Safari iepengiet, in dokumint dat fia it dielblêd trochjûn wurdt, of in SSO-oanmelding dy't oergiet nei in browser ferlitt it proses fan de app en de tunnel dermei. In oanmelding dy't binnen de app toand wurdt, wurdt meast oan de app taskood, dus in ynboude oanmelding kin slagje wêr't deselde URL yn Safari mislearret; ferifiearje dat ynstee fan it oan te nimmen. As de identiteitsprovider allinne fia de tunnel berikber is, hâld de oanmelding dan binnen de app of foege it providerdomein ta oan 'e Safari-domeinen fan 'e payload sadat oerienkommend Safari-ferkear fongen wurdt.
Keppel it symptoom oan 'e laach
De foarm fan 'e flater fertelt jo hokker kontrôle te werheljen.
| 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 |
Efter de middelste rigen sitte twa details: in per-app-tunnel kin sûn wêze en dochs in subnet misse dat gjin providerlist befettet, en in behearder telefoan kin mear as ien VPN-konfiguraasje hâlde, dus befêstigje oan hokker de app bûn is ynstee fan oan te nimmen dat it dy is dy't jo lêze.
Reparearje yn dizze oarder: korrizje de app-registraasje sadat dy nei de libbene payload wiist, ynstallearje de app op 'e nij fia behear, befêstigje dat de tunnel by it earste fersyk fan de app omheech komt, en werhelje dan de namme- en grinzetests. As it earste fersyk hielendal gjin tunnel starte kin, stopje en kontrolearje de providerkant, want in oanpaste klant hat syn Network Extension nedich, oanwêzich mei in identifikaasje dy't by de ynstallearre app past.
Jou trije feiten werom ynstee fan in skermôfdruk: nei hokker payload de app-registraasje wiist, oft Ynstellings it as ynstallearre profyl sjen litte, en wat it mislearre fersyk wie, in namme, in adres of in browser-oerdracht. Dy trije antwurden skiede in útrôlflater fan in rûteflater, en de folgjende persoan kin hannelje sûnder de diagnoaze te werheljen.