La semaine dernière, un collègue m’a tendu son iPhone avec deux entrées VPN dans Réglages : l’une laissée par une application de fournisseur, l’autre issue d’un profil IKEv2 copié depuis une page d’assistance. Ce ne sont pas deux versions concurrentes de la même chose. Une application de fournisseur est un conteneur qui peut embarquer son propre code de tunnel, tandis que le client intégré d’Apple est un client IKEv2, configuré à la main ou par un profil. Le protocole, la gestion des identifiants, le contrôle de l’appareil et la reprise décident du choix.

L’application et le client natif ne se situent pas au même niveau

Le client VPN intégré d’Apple est en pratique un client IKEv2. Le formulaire manuel liste encore l’ L2TP sur IPsec et les options Cisco IPsec, mais il n’y a aucun champ de transport fournisseur et aucun endroit où coller une configuration OpenVPN ou WireGuard. Soit vous remplissez un formulaire dans Réglages > Général > VPN & Gestion de l’appareil, soit vous importez un profil contenant une charge VPN ; la surface se limite à une adresse de serveur, deux identités, une méthode d’authentification et des règles à la demande facultatives.

Une application de fournisseur travaille un niveau au-dessus. Elle embarque un fournisseur de tunnel de paquets Network Extension, si bien que le code du protocole et la logique de routage vivent dans l’application et qu’iOS ne fait que transmettre les paquets. Certaines applications implémentent WireGuard ou OpenVPN, d’autres un transport obscurci maison, et quelques-unes installent seulement un profil IKEv2 et pilotent le client natif derrière un écran plus agréable. C’est ce dernier groupe qui fait parfois de l’opposition application-profil un faux choix.

La conséquence est pratique : un fichier .ovpn ou WireGuard ne remplace pas ces champs, car la poignée de main est un autre protocole.

Lisez la charge avant de comparer les fonctionnalités

Lorsque le profil est IKEv2, les clés de la charge expliquent plus de pannes que n’importe quelle comparaison de fonctionnalités. La référence des réglages IKEv2 d’Apple documente chaque clé ; une charge tronquée ressemble à ceci :

<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>

Trois champs portent l’essentiel du diagnostic. RemoteIdentifier est le nom que le client attend du serveur, si bien qu’une passerelle derrière NAT ou un répartiteur de charge dont le certificat nomme le pool plutôt que l’adresse échoue alors que l’adresse est correcte. LocalIdentifier est l’identité que le serveur vous attribue, et avec l’authentification par certificat, elle doit correspondre à l’identité associée à votre compte. ServerCertificateIssuerCommonName épingle l’autorité de certification émettrice, si bien qu’un profil peut échouer le jour où le certificat est réémis, sans aucun message d’erreur mentionnant les certificats.

Si AuthenticationMethod vaut SharedSecret, le serveur fait de l’authentification utilisateur EAP et le secret qu’on vous a remis est en réalité un identifiant de compte. Cela compte lorsqu’un fournisseur envoie deux documents, l’un pour le nom d’utilisateur et le mot de passe, l’autre pour un certificat, et qu’un seul correspond à ce que vous avez importé.

Ce que l’application peut faire et que le client natif ne peut pas

Le choix du protocole est l’avantage évident. Si votre serveur parle WireGuard ou OpenVPN, une application est le seul client iOS capable de l’utiliser, et modifier le formulaire natif ne le négociera pas. Une application peut aussi implémenter le tunnel divisé par destination ou par application, sa propre gestion DNS, un blocage de type kill switch, la sélection de serveur et une reconnexion ajustée à son propre réseau.

Le prix à payer est un logiciel que vous n’avez pas audité, exécuté avec les privilèges d’une extension réseau. La qualité varie plus que ne le suggèrent les fiches du store : une application se reconnecte proprement tandis qu’une autre fuit quelques secondes après un changement de réseau, et un kill switch dans l’application est une fonction de cette application, pas d’iOS. Sur un appareil géré, vérifiez d’abord la liste approuvée.

Ce que le profil IKEv2 natif fait correctement

Moins de pièces mobiles, c’est tout l’argument. Le client IKEv2 et sa pile IPsec sont livrés avec le système, donc il n’y a pas d’extension à faire planter, pas de processus par application à maintenir en vie et pas de cycle de mises à jour tierces entre vous et un tunnel qui fonctionne. Un profil peut aussi être verrouillé : sur un appareil supervisé, l’utilisateur ne peut pas supprimer ce que la gestion a installé, et Always On VPN, qui se reconnecte sur n’importe quel réseau sans interrupteur utilisateur, n’existe que sous cette forme supervisée et gérée par profil.

Ce que le chemin natif ne vous donne pas, c’est la flexibilité. Pas de VPN par application sans applications gérées, pas de kill switch côté utilisateur et pas de transport qui ressemble à HTTPS sur un réseau bloquant IPsec. Sur les réseaux d’hôtel qui abandonnent UDP 500 et 4500, IKEv2 natif n’a pas de repli.

Un tableau de décision qui règle la plupart des cas

En pratique, la question du protocole tranche la plupart des cas avant que les fonctionnalités ne comptent.

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

Deux lignes méritent un second regard. Une exigence par application sur un téléphone personnel est le cas que les gens lisent mal : le réglage existe dans iOS mais est piloté par la gestion, donc un appareil non géré ne le proposera pas. Un réseau bloqué n’est pas une raison de se méfier d’IKEv2 ; c’est la raison pour laquelle l’application du fournisseur existe.

Vérifiez le choix avec un essai

Testez les modes de panne, pas le bouton de connexion. Connectez-vous une fois, confirmez que l’indicateur VPN apparaît, puis ouvrez une page qui renvoie votre adresse publique et comparez-la avec la précédente. Passez du Wi-Fi au réseau mobile sans toucher au VPN et guettez une reconnexion, puis faites passer le téléphone en mode avion. Redémarrez et voyez si le tunnel revient tout seul : un profil avec OnDemandEnabled devrait le faire, tandis que beaucoup d’applications doivent d’abord être ouvertes.

Quand il ne revient pas, séparez la panne selon qu’un tunnel existe ou non. Pas d’indicateur VPN signifie que le tunnel n’a jamais démarré : soit la poignée de main a échoué sur RemoteIdentifier, sur l’autorité de certification épinglée ou sur un identifiant, soit la connexion n’a jamais été tentée parce que la règle à la demande ne correspondait pas et qu’aucune application ne l’a lancée. Un indicateur avec un trafic en échec signifie routage, DNS ou politique côté serveur, et réinstaller le client n’y touche pas.

Une courte liste pour laisser l’appareil explicable à la personne suivante :

  • une entrée VPN, pas deux ;
  • le profil ou l’application nommé d’après le serveur auquel il se connecte ;
  • les valeurs d’identité notées là où vous pourrez les retrouver.

Commencez par la ligne du protocole dans le tableau, et arrêtez-vous là si elle répond à la question.

Articles similaires