VPN per aplicació a apps gestionades de l'iPhone: què s'encamina i què no
Un túnel per aplicació segueix l'app gestionada, no el telèfon. Comproveu l'associació del perfil, la còpia gestionada, les regles sota demanda i els fluxos que surten de l'app.
La VPN per aplicació a l'iPhone no és un interruptor per a tot el telèfon. És una associació entre una app gestionada i un perfil de VPN, creada quan es desplega l'app, i el trànsit de la resta conserva la ruta que tenia abans. Per això el mateix telèfon es comporta de manera inconsistent: l'app de feina obre una pàgina privada mentre Safari no arriba al mateix amfitrió, o el túnel no s'aixeca mai i l'app informa d'un temps d'espera que sembla unes credencials dolentes. Les comprovacions van de la causa més àmplia cap avall, així que atureu-vos a la primera que falli.
Comproveu primer el perfil i el registre de l'app
L'associació viu en dos objectes, no en un. El perfil de VPN defineix el túnel: tipus, servidor, autenticació, DNS i l'identificador del paquet del proveïdor quan s'usa un client personalitzat. El registre de l'app apunta a aquest perfil, i la majoria de consoles de gestió ho ofereixen com a opció per aplicació a la configuració de l'app, amb un nom proper a Per-App VPN. Un perfil que cap app assenyala no encamina res per aplicació; es comporta com un túnel ordinari que algú ha d'iniciar a mà.
Llegiu tots dos objectes abans de tocar el telèfon. Confirmeu que la configuració de l'app fa referència al perfil que proveu i no a una còpia antiga, perquè els perfils duplicats amb noms gairebé idèntics són habituals després d'una migració i l'app apuntarà de bon grat al retirat. Després confirmeu que la configuració ha arribat al dispositiu: Configuració, General, VPN i gestió del dispositiu l'han de mostrar com a perfil instal·lat. La llista de VPN d'allà no és la prova. Un servei per aplicació normalment no té interruptor manual, així que una configuració desplegada correctament pot no aparèixer mai entre les VPN que es poden iniciar. L'absència es veu al registre de l'app i en si el túnel s'aixeca a la primera petició de l'app.
Una condició explica molts tiquets: aquest model necessita que l'app arribi a través de la gestió. Una còpia instal·lada de costat o comprada personalment no obté l'associació, encara que el seu identificador de paquet coincideixi. La guia de desplegament de VPN d'Apple descriu el model de perfil que hi ha al darrere (support.apple.com/guide/deployment/vpn-overview-depae3d361d0/web).
Confirmeu que l'app instal·lada és la còpia gestionada
L'associació segueix l'app instal·lada i gestionada. Si algú la reinstal·la des de l'App Store amb un Apple ID personal, la substitueix per una compilació empresarial re-signada o el dispositiu es torna a inscriure i l'app torna per un altre canal, el túnel pot quedar aturat mentre l'app sembla del tot normal.
Proveu per comparació, no amb una sola observació. A l'inventari de gestió, l'app ha de constar com a gestionada per a aquell dispositiu amb el mapatge de VPN al registre. Al telèfon, el túnel s'ha d'aixecar quan es llança l'app i surt la primera petició, no només quan algú inicia una configuració manual a part a Configuració. Si llançar l'app no canvia res i aquella configuració manual sí, l'app no està vinculada a cap túnel per aplicació.
Les actualitzacions importen: la que s'envia per gestió conserva el mapatge, mentre que una reinstal·lació iniciada per l'usuari el pot perdre. Quan la queixa data d'una actualització, mireu el registre de l'app abans de la xarxa.
Comproveu què pot prendre el túnel
Un túnel per aplicació se selecciona per l'app d'origen, així que la ruta per defecte del telèfon encara pertany al Wi-Fi o a la xarxa mòbil. OverridePrimary és la clau que ho canvia. Quan un perfil la defineix, el túnel es comporta com un túnel complet i totes les apps l'hereten, de manera que tot el que passa per la VPN esdevé una qüestió de perfil i no una fallada de l'app.
Les regles sota demanda decideixen la persistència. OnDemandEnabled i el seu conjunt de regles fan que el túnel torni quan l'app envia trànsit, sobrevisqui un canvi de Wi-Fi a xarxa mòbil o caigui quan l'app passa a segon pla. Un desplegament que es connecta i després mor en silenci sol tenir una regla que només coincideix amb una sonda que mai s'activa mentre l'app està inactiva.
Després llegiu la banda de rutes amb sinceritat. Si un perfil de proveïdor o de fabricant aporta una llista d'inclusió, un túnel que només porta 10.20.0.0/16 no portarà un servei a 10.30.0.0/16; és la llista fent la seva feina, no una fallada per aplicació. El perfil integrat d'iOS no té llista d'inclusió. Sense una, la divisió segueix els valors per defecte del proveïdor i IncludeAllNetworks, no una llista oculta.
Proveu l'app i després què en surt
Proveu amb un nom, no només amb una adreça. Resoldre un amfitrió intern dins de l'app gestionada demostra que el DNS també ha passat pel túnel, perquè el perfil decideix quin resolutor respon i quins dominis de cerca s'apliquen. L'encaminament pot ser perfecte mentre la consulta de nom falla, i els dos símptomes apunten a paràmetres diferents.
Després proveu el límit des de les dues bandes. Una app personal o Safari ha d'arribar a una pàgina pública ordinària i informar de l'adreça de l'operador o de casa, mentre que l'app gestionada arriba al servei privat. Si totes dues informen de la mateixa adreça pública, el túnel ja no és per aplicació, digui el que digui el registre de l'app.
Els fluxos que surten de l'app produeixen els tiquets confusos. Un enllaç que s'obre a Safari, un document passat pel full de compartició o un inici de sessió SSO que passa a un navegador surten del procés de l'app i del túnel amb ell. Un inici de sessió mostrat dins de l'app normalment s'atribueix a l'app, així que un inici incrustat pot reeixir on la mateixa URL falla a Safari; verifiqueu-ho en lloc de suposar-ho. Quan el proveïdor d'identitat només és accessible pel túnel, o manteniu l'inici dins de l'app o afegiu el domini del proveïdor als dominis de Safari del perfil perquè el trànsit de Safari coincident es capturi.
Aparelleu el símptoma amb la capa
La forma de la fallada us diu quina comprovació heu de repetir.
| 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 |
Darrere de les files del mig hi ha dos detalls: un túnel per aplicació pot estar sa i tot i així perdre una subxarxa que cap llista de proveïdor inclou, i un telèfon gestionat pot tenir més d'una configuració de VPN, així que confirmeu a quina està vinculada l'app en lloc de suposar que és la que llegiu.
Repareu en aquest ordre: corregiu el registre de l'app perquè faci referència al perfil viu, reinstal·leu l'app a través de la gestió, confirmeu que el túnel s'aixeca a la primera petició de l'app i repetiu les proves de nom i de límit. Si la primera petició no pot iniciar cap túnel, atureu-vos i mireu el costat del proveïdor, perquè un client personalitzat necessita el Network Extension present i el seu identificador coincident amb l'app instal·lada.
Torneu tres fets en lloc d'una captura de pantalla: a quin perfil fa referència el registre de l'app, si Configuració el mostra com a perfil instal·lat i quina era la petició que fallava, un nom, una adreça o un traspàs al navegador. Aquestes tres respostes separen un error de desplegament d'un d'encaminament, i la persona següent pot actuar sense repetir el diagnòstic.