VPN por aplicación nas apps xestionadas do iPhone: que se encamiña e que non
Un túnel por aplicación segue a app xestionada, non o teléfono. Comprobe a asociación do perfil, a copia xestionada, as regras baixo demanda e os fluxos que saen da app.
A VPN por aplicación no iPhone non é un interruptor para todo o teléfono. É unha asociación entre unha app xestionada e un perfil de VPN, creada cando se despregá a app, e o tráfico de todo o demais conserva a ruta que tiña antes. Por iso o mesmo teléfono compórtase de forma incoherente: a app de traballo abre unha páxina privada mentres Safari non chega ao mesmo host, ou o túnel non levanta e a app informa dun tempo de espera que parece credenciais incorrectas. As comprobacións van da causa máis ampla cara abaixo, así que detéñase na primeira que falle.
Comprobe primeiro o perfil e o rexistro da app
A asociación vive en dous obxectos, non nun. O perfil de VPN define o túnel: tipo, servidor, autenticación, DNS e o identificador de paquete do provedor cando se usa un cliente personalizado. O rexistro da app apunta a ese perfil, e a maioría de consolas de xestión ofréceno como opción por aplicación na configuración da app, cun nome próximo a Per-App VPN. Un perfil ao que non apunta ningunha app non encamiña nada por aplicación; compórtase como un túnel normal que alguén debe iniciar a man.
Lea ambos obxectos antes de tocar o teléfono. Confirme que a configuración da app fai referencia ao perfil que proba e non a unha copia antiga, porque os perfís duplicados con nomes case idénticos son habituais tras unha migración e a app apuntará de bo grao ao retirado. Despois confirme que a configuración chegou ao dispositivo: Axustes, Xeral, VPN e xestión de dispositivos debe mostrala como perfil instalado. A lista de VPN de alí non é a proba. Un servizo por aplicación normalmente non ten interruptor manual, así que unha configuración despregada correctamente pode non aparecer nunca entre as VPN que se poden iniciar. A ausencia vese no rexistro da app e en se o túnel levanta na primeira petición da app.
Unha condición explica moitos tickets: este modelo necesita que a app chegue a través da xestión. Unha copia instalada por outra vía ou comprada persoalmente non obtén a asociación, aínda que o seu identificador de paquete coincida. A guía de despregamento de VPN de Apple describe o modelo de perfil que hai detrás (support.apple.com/guide/deployment/vpn-overview-depae3d361d0/web).
Confirme que a app instalada é a copia xestionada
A asociación segue a app instalada e xestionada. Se alguén a reinstalou desde o App Store cun Apple ID persoal, substituíuna por unha compilación empresarial re-asinada ou o dispositivo volveuse inscribir e a app volveu por outra canle, o túnel pode quedar abaixo mentres a app parece completamente normal.
Probe por comparación, non cunha soa observación. No inventario de xestión, a app debe figurar como xestionada para ese dispositivo coa asignación de VPN no seu rexistro. No teléfono, o túnel debe levantar cando se lanza a app e sae a súa primeira petición, non só cando alguén inicia unha configuración manual aparte en Axustes. Se lanzar a app non cambia nada e esa configuración manual si, a app non está vinculada a ningún túnel por aplicación.
As actualizacións importan: a que se envía por xestión conserva a asignación, mentres que unha reinstalación iniciada polo usuario pode perdela. Cando a queixa data dunha actualización, mire o rexistro da app antes que a rede.
Comprobe que pode tomar o túnel
Un túnel por aplicación selecciónase pola app de orixe, así que a ruta predeterminada do teléfono segue pertencendo ao Wi-Fi ou á rede móbil. OverridePrimary é a clave que cambia iso. Cando un perfil a establece, o túnel compórtase como un túnel completo e todas as apps herédano, de modo que todo o que pasa pola VPN convértese nunha cuestión de perfil e non nun fallo da app.
As regras baixo demanda deciden a persistencia. OnDemandEnabled e o seu conxunto de regras fan que o túnel volva cando a app envía tráfico, sobreviva a un cambio de Wi-Fi a rede móbil ou caia cando a app pasa a segundo plano. Un despregamento que se conecta e logo morre en silencio adoita ter unha regra que só coincide cunha sonda que nunca se activa mentres a app está inactiva.
Despois lea o lado das rutas con honestidade. Se un perfil de provedor ou de fabricante achega unha lista de inclusión, un túnel que só leva 10.20.0.0/16 non levará un servizo en 10.30.0.0/16; é a lista facendo o seu traballo, non un fallo por aplicación. O perfil integrado de iOS non ten lista de inclusión. Sen unha, a división segue os valores predeterminados do provedor e IncludeAllNetworks, non unha lista oculta.
Probe a app e despois que sae dela
Probe cun nome, non só cun enderezo. Resolver un host interno dentro da app xestionada demostra que o DNS tamén pasou polo túnel, porque o perfil decide que resolutor responde e que dominios de busca se aplican. O encamiñamento pode ser perfecto mentres falla a busca de nomes, e os dous síntomas apuntan a axustes distintos.
Despois probe o límite desde ambos os lados. Unha app persoal ou Safari debería chegar a unha páxina pública normal e informar do enderezo do operador ou da casa, mentres que a app xestionada chega ao servizo privado. Se ambas informan do mesmo enderezo público, o túnel xa non é por aplicación, diga o que diga o rexistro da app.
Os fluxos que saen da app producen os tickets confusos. Unha ligazón que se abre en Safari, un documento pasado pola folla de compartir ou un inicio de sesión SSO que pasa a un navegador saen do proceso da app e do túnel con el. Un inicio de sesión mostrado dentro da app atribúese normalmente á app, así que un inicio integrado pode funcionar onde o mesmo URL falla en Safari; verifíqueo en lugar de supoñelo. Cando o provedor de identidade só é accesible polo túnel, ou mantén o inicio dentro da app ou engade o dominio do provedor aos dominios de Safari do perfil para que se capture o tráfico de Safari coincidente.
Emparelle o síntoma coa capa
A forma do fallo dille que comprobación 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 |
Detrás das filas centrais hai dous detalles: un túnel por aplicación pode estar san e aínda así perder unha subrede que ningunha lista de provedor inclúe, e un teléfono xestionado pode ter máis dunha configuración de VPN, así que confirme a cal está vinculada a app en lugar de supoñer que é a que le.
Corrixa nesta orde: arranxe o rexistro da app para que faga referencia ao perfil activo, reinstale a app a través da xestión, confirme que o túnel levanta na primeira petición da app e repita as probas de nome e de límite. Se a primeira petición non pode iniciar ningún túnel, detéñase e mire o lado do provedor, porque un cliente personalizado necesita o seu Network Extension presente e o seu identificador coincidente coa app instalada.
Devolva tres feitos en lugar dunha captura: a que perfil fai referencia o rexistro da app, se Axustes o mostra como perfil instalado e cal foi a petición que fallou, un nome, un enderezo ou un traspaso ao navegador. Esas tres respostas separan un erro de despregamento dun de encamiñamento, e a seguinte persoa pode actuar sen repetir o diagnóstico.