VPN per app sulle app iPhone gestite: cosa viene instradato e cosa no

Il VPN per app su iPhone non è un interruttore per tutto il telefono. È un'associazione tra un'app gestita e un profilo VPN, creata quando l'app viene distribuita, e il traffico di tutto il resto conserva la rotta che aveva prima. Per questo lo stesso telefono si comporta in modo incoerente: l'app di lavoro apre una pagina privata mentre Safari non raggiunge lo stesso host, oppure il tunnel non sale affatto e l'app segnala un timeout che sembra credenziali errate. I controlli vanno dalla causa più ampia verso il basso, quindi fermatevi al primo che fallisce.

Controllate prima il profilo e il record dell'app

L'associazione vive in due oggetti, non in uno. Il profilo VPN definisce il tunnel: tipo, server, autenticazione, DNS e l'identificatore del pacchetto del provider quando si usa un client personalizzato. Il record dell'app punta a quel profilo, e la maggior parte delle console di gestione lo offre come opzione per app nella configurazione dell'app, con un nome vicino a Per-App VPN. Un profilo a cui nessuna app punta non instrada nulla per app; si comporta come un tunnel ordinario che qualcuno deve avviare a mano.

Leggete entrambi gli oggetti prima di toccare il telefono. Confermate che la configurazione dell'app faccia riferimento al profilo che state testando e non a una copia precedente, perché i profili duplicati con nomi quasi identici sono comuni dopo una migrazione e l'app punterà volentieri a quello ritirato. Poi confermate che la configurazione sia arrivata al dispositivo: Impostazioni, Generali, VPN e gestione del dispositivo devono mostrarla come profilo installato. L'elenco VPN lì non è il test. Un servizio per app di solito non ha un interruttore manuale, quindi una configurazione distribuita correttamente potrebbe non apparire mai tra i VPN avviabili. L'assenza si vede nel record dell'app e nel fatto che il tunnel salga alla prima richiesta dell'app.

Una condizione spiega molti ticket: questo modello richiede che l'app arrivi tramite la gestione. Una copia installata di lato o acquistata personalmente non ottiene l'associazione, anche quando il suo identificatore di pacchetto corrisponde. La guida al deployment VPN di Apple descrive il modello di profilo che sta dietro (support.apple.com/guide/deployment/vpn-overview-depae3d361d0/web).

Confermate che l'app installata sia la copia gestita

L'associazione segue l'app installata e gestita. Se qualcuno l'ha reinstallata dall'App Store con un Apple ID personale, l'ha sostituita con una build aziendale rifirmata o il dispositivo è stato reiscritto e l'app è tornata da un altro canale, il tunnel può restare giù mentre l'app stessa sembra del tutto normale.

Testate per confronto, non con una singola osservazione. Nell'inventario di gestione l'app deve risultare gestita per quel dispositivo con la mappatura VPN nel record. Sul telefono il tunnel deve salire all'avvio dell'app e all'uscita della sua prima richiesta, non solo quando qualcuno avvia una configurazione manuale separata in Impostazioni. Se avviare l'app non cambia nulla e quella configurazione manuale sì, l'app non è affatto legata a un tunnel per app.

Gli aggiornamenti contano: quello inviato tramite gestione conserva la mappatura, mentre una reinstallazione avviata dall'utente può perderla. Quando la segnalazione data da un aggiornamento, controllate il record dell'app prima della rete.

Controllate cosa può prendere il tunnel

Un tunnel per app è selezionato dall'app di origine, quindi la rotta predefinita del telefono appartiene ancora al Wi-Fi o alla rete cellulare. OverridePrimary è la chiave che lo cambia. Quando un profilo la imposta, il tunnel si comporta come un tunnel completo e ogni app lo eredita, così tutto ciò che passa dal VPN diventa una questione di profilo e non un guasto dell'app.

Le regole su richiesta decidono la persistenza. OnDemandEnabled e il suo set di regole fanno tornare il tunnel quando l'app invia traffico, sopravvivere a un passaggio dal Wi-Fi alla rete cellulare o cadere quando l'app va in background. Un deployment che si connette e poi muore in silenzio di solito ha una regola che corrisponde solo a una sonda che non si attiva mai mentre l'app è inattiva.

Poi leggete il lato rotte con onestà. Se un profilo del provider o del fornitore fornisce una lista di inclusione, un tunnel che porta solo 10.20.0.0/16 non porterà un servizio in 10.30.0.0/16; è la lista che fa il suo lavoro, non un guasto per app. Il profilo iOS integrato non ha una lista di inclusione. Senza, la divisione segue i valori predefiniti del provider e IncludeAllNetworks, non una lista nascosta.

Testate l'app, poi ciò che ne esce

Testate con un nome, non solo con un indirizzo. Risolvere un host interno dentro l'app gestita dimostra che anche il DNS è passato dal tunnel, perché il profilo decide quale resolver risponde e quali domini di ricerca si applicano. L'instradamento può essere perfetto mentre la risoluzione del nome fallisce, e i due sintomi indicano impostazioni diverse.

Poi testate il confine da entrambi i lati. Un'app personale o Safari dovrebbe raggiungere una pagina pubblica ordinaria e riportare l'indirizzo dell'operatore o di casa, mentre l'app gestita raggiunge il servizio privato. Se entrambe riportano lo stesso indirizzo pubblico, il tunnel non è più per app, qualunque cosa affermi il record dell'app.

I flussi che escono dall'app producono i ticket confusi. Un link che si apre in Safari, un documento passato dal foglio di condivisione o un accesso SSO che passa a un browser lasciano il processo dell'app e il tunnel con sé. Un accesso mostrato dentro l'app è di solito attribuito all'app, quindi un accesso incorporato può riuscire dove lo stesso URL fallisce in Safari; verificatelo invece di presumerlo. Quando il provider di identità è raggiungibile solo tramite il tunnel, tenete l'accesso dentro l'app oppure aggiungete il dominio del provider ai domini Safari del profilo perché il traffico Safari corrispondente venga catturato.

Abbinate il sintomo al livello

La forma del guasto vi dice quale controllo ripetere.

Dietro le righe centrali ci sono due dettagli: un tunnel per app può essere sano e mancare comunque una sottorete che nessuna lista del provider include, e un telefono gestito può contenere più di una configurazione VPN, quindi confermate a quale è legata l'app invece di supporre che sia quella che leggete.

Correggete in questo ordine: sistemate il record dell'app perché faccia riferimento al profilo attivo, reinstallate l'app tramite la gestione, confermate che il tunnel salga alla prima richiesta dell'app, poi ripetete i test di nome e confine. Se la prima richiesta non riesce ad avviare alcun tunnel, fermatevi e controllate il lato provider, perché un client personalizzato ha bisogno del suo Network Extension presente e del suo identificatore corrispondente all'app installata.

Restituite tre fatti invece di uno screenshot: a quale profilo fa riferimento il record dell'app, se Impostazioni lo mostra come profilo installato e quale era la richiesta fallita, un nome, un indirizzo o un passaggio al browser. Quelle tre risposte separano un errore di deployment da uno di instradamento, e la persona successiva può agire senza ripetere la diagnosi.