La settimana scorsa un collega mi ha passato il suo iPhone con due voci VPN in Impostazioni: una lasciata da un’app del fornitore, una da un profilo IKEv2 copiato da una pagina di assistenza. Non sono versioni concorrenti della stessa cosa. Un’app del fornitore è un contenitore che può portare il proprio codice di tunnel, mentre il client integrato di Apple è un client IKEv2, configurato a mano o tramite un profilo. Protocollo, gestione delle credenziali, controllo del dispositivo e ripristino decidono la scelta.

L’app e il client nativo stanno su livelli diversi

Il client VPN integrato di Apple è in pratica un client IKEv2. Il modulo manuale elenca ancora l’opzione deprecata L2TP su IPsec e le opzioni Cisco IPsec, ma non c’è alcun campo di trasporto del fornitore né un posto dove incollare una configurazione OpenVPN o WireGuard. O compili un modulo in Impostazioni > Generali > VPN & Gestione dispositivo, oppure importi un profilo che contiene un payload VPN; la superficie è un indirizzo di server, due identità, un metodo di autenticazione e regole on demand facoltative.

Un’app del fornitore lavora un livello sopra. Include un packet tunnel provider di Network Extension, così il codice del protocollo e la logica di routing vivono nell’app e iOS si limita a far passare i pacchetti. Alcune app implementano WireGuard o OpenVPN, altre un trasporto offuscato proprio, e alcune installano solo un profilo IKEv2 e guidano il client nativo dietro una schermata più gradevole. È quest’ultimo gruppo che rende talvolta falsa la scelta tra app e profilo.

La conseguenza è pratica: un file .ovpn o WireGuard non sostituisce quei campi, perché l’handshake è un altro protocollo.

Leggi il payload prima di confrontare le funzioni

Quando il profilo è IKEv2, le chiavi del payload spiegano più guasti di qualsiasi confronto tra funzioni. Il riferimento alle impostazioni IKEv2 di Apple documenta ogni chiave; un payload ridotto appare così:

<key>VPNType</key><string>IKEv2</string>
<key>RemoteAddress</key><string>vpn.example.net</string>
<key>RemoteIdentifier</key><string>vpn.example.net</string>
<key>LocalIdentifier</key><string>[email protected]</string>
<key>AuthenticationMethod</key><string>Certificate</string>
<key>ServerCertificateIssuerCommonName</key><string>Example Issuing CA</string>

Tre campi portano gran parte del peso diagnostico. RemoteIdentifier è il nome che il client si aspetta dal server, quindi un gateway dietro NAT o un bilanciatore il cui certificato nomina il pool invece dell’indirizzo fallisce anche se l’indirizzo è corretto. LocalIdentifier è chi il server ritiene che tu sia, e con l’autenticazione a certificato deve corrispondere all’identità associata al tuo account. ServerCertificateIssuerCommonName fissa la CA emittente, quindi un profilo può fallire il giorno in cui il certificato viene riemesso, senza alcun messaggio di errore che parli di certificati.

Se AuthenticationMethod è SharedSecret, il server esegue autenticazione utente EAP e il segreto che ti hanno dato è in realtà una credenziale dell’account. Questo conta quando un fornitore invia due documenti, uno per nome utente e password e uno per un certificato, e solo uno corrisponde a ciò che hai importato.

Ciò che l’app può fare e il client nativo no

La scelta del protocollo è il vantaggio ovvio. Se il tuo server parla WireGuard o OpenVPN, un’app è l’unico client iOS che può usarlo, e modificare il modulo nativo non lo negozierà. Un’app può anche implementare lo split tunnelling per destinazione o per app, una propria gestione DNS, un blocco in stile kill switch, la selezione del server e una riconnessione tarata sulla propria rete.

Il prezzo è software che non hai verificato, in esecuzione con i privilegi di una network extension. La qualità varia più di quanto suggeriscano le schede dello store: un’app si riconnette in modo pulito mentre un’altra perde pacchetti per qualche secondo dopo un cambio di rete, e un kill switch dentro l’app è una funzione di quell’app, non di iOS. Su un dispositivo gestito, controlla prima l’elenco approvato.

Ciò che il profilo IKEv2 nativo fa bene

Meno parti in movimento è l’intero argomento. Il client IKEv2 e il suo stack IPsec arrivano con il sistema, quindi non c’è un’estensione che possa bloccarsi, nessun processo per app da tenere in vita e nessun ciclo di aggiornamenti di terzi tra te e un tunnel funzionante. Un profilo può anche essere bloccato: su un dispositivo supervisionato l’utente non può rimuovere ciò che la gestione ha installato, e Always On VPN, che si riconnette su qualsiasi rete senza interruttore utente, esiste solo in quella forma supervisionata e gestita da profilo.

Ciò che la via nativa non ti dà è la flessibilità. Non esiste VPN per app senza app gestite, né kill switch lato utente, né un trasporto che somigli a HTTPS su una rete che blocca IPsec. Nelle reti alberghiere che scartano UDP 500 e 4500, IKEv2 nativo non ha ripiego.

Una tabella decisionale che risolve la maggior parte dei casi

In pratica la domanda sul protocollo decide la maggior parte dei casi prima che le funzioni contino.

What you were givenDevice situationWhat to use
An .ovpn or WireGuard configPersonal phoneProvider app; the native form cannot load it
IKEv2 host plus CA namePersonal or managedProfile, or the app's own IKEv2 mode
IKEv2 with username and secretPersonal phoneEither; the profile is simpler if you never switch servers
A management-installed profileSupervised, MDMNative client; do not add a second app entry
A per-app tunnelling requirementPersonal phoneApp, or accept a full tunnel; iOS cannot split by app without management
IPsec blocked on your main networkAnyApp with a transport that survives the block

Due righe meritano un secondo sguardo. Un requisito per app su un telefono personale è il caso che le persone fraintendono: l’impostazione esiste in iOS ma è guidata dalla gestione, quindi un dispositivo non gestito non la offrirà. Una rete bloccata non è un motivo per diffidare di IKEv2; è il motivo per cui esiste l’app del fornitore.

Verifica la scelta con una prova

Prova i modi di fallire, non il pulsante di connessione. Connettiti una volta, conferma che appaia l’indicatore VPN, poi apri una pagina che restituisce il tuo indirizzo pubblico e confrontalo con il precedente. Passa dal Wi-Fi ai dati cellulari senza toccare la VPN e osserva la riconnessione, poi porta il telefono in modalità aereo. Riavvia e vedi se il tunnel torna da solo: un profilo con OnDemandEnabled dovrebbe, mentre molte app devono prima essere aperte.

Quando non torna, separa il guasto a seconda che esista un tunnel. Nessun indicatore VPN significa che il tunnel non è mai salito: o l’handshake è fallito su RemoteIdentifier, sulla CA fissata o su una credenziale, oppure la connessione non è mai stata tentata perché la regola on demand non corrispondeva e nessuna app l’ha avviata. Un indicatore con traffico che fallisce significa routing, DNS o criterio lato server, e reinstallare il client non tocca nulla di tutto ciò.

Una breve lista per lasciare il dispositivo spiegabile alla persona successiva:

  • una voce VPN, non due;
  • il profilo o l’app intitolato al server a cui si connette;
  • i valori di identità annotati dove puoi trovarli.

Parti dalla riga del protocollo nella tabella, e fermati lì se risponde alla domanda.

Articoli correlati