IKEv2 sur iPhone : que saisir dans les champs « Serveur », « ID distant » et « ID local »

En résumé : dans « Serveur », on indique généralement le nom de domaine ou l’adresse IP de votre serveur VPN ; dans « ID distant », un identifiant qui doit correspondre à ce que le serveur attend (souvent le nom de domaine indiqué dans le certificat serveur) ; dans « ID local », un identifiant client que le serveur utilise pour appliquer des règles (souvent laissé vide ou rempli avec le nom d’utilisateur/ID fourni par le prestataire). Prenez toujours ces valeurs directement auprès de votre fournisseur ou administrateur : des saisies au hasard sont une cause fréquente d’erreur lors de la vérification du certificat ou de refus de connexion.

Que signifient les champs IKEv2 sous iOS et à quoi servent-ils

Avec IKEv2 (IPsec), les parties échangent des paramètres et confirment leurs identités. Sur iPhone, trois champs posent souvent question :

• Serveur — l’adresse de connexion (IP du VPN ou nom de domaine du serveur).
• ID distant (Remote ID) — « comment je vérifie le serveur » ; c’est la chaîne que iOS utilise pour associer le serveur à son certificat (habituellement les données contenues dans le certificat).
• ID local (Local ID) — « comment le serveur me reconnaît » ; identifiant client que le serveur peut vérifier ou exploiter dans ses règles.

Ces valeurs interviennent dans l’authentification. Si elles ne correspondent pas aux réglages du serveur et au certificat, iOS pourrait ne pas faire confiance, ou le serveur refusera la connexion. Pour une vérification approfondie, consultez la documentation Apple sur IKEv2/IPsec : Apple : paramètres de gestion des appareils IKEv2.

Champ « Serveur » : domaine ou IP et comment savoir quoi renseigner

Ce qui est le plus souvent saisi

• Nom de domaine complet (FQDN), par exemple vpn.example.com — le choix courant, pratique en cas de changement d’IP et indispensable pour le bon fonctionnement du certificat.
• Adresse IP — parfois utilisée pour des tests rapides ou en l’absence de domaine. Cependant, pour la vérification du certificat « ID distant » reste essentiel.

Avant d’agir : vérifier

• Confirmez avec votre fournisseur si la connexion doit se faire via un nom de domaine ou une IP. Si un domaine et un certificat sont fournis, il vaut mieux privilégier le domaine.
• Si vous utilisez une IP, vérifiez qu’elle est fixe (évitez les adresses dynamiques). Un changement fréquent d’IP peut provoquer des connexions instables.

Mesures sûres (réversibles)

• Commencez toujours par ce que préconise l’instruction de votre fournisseur. Ne désactivez jamais la vérification du certificat en cas d’erreur, ni ne recourez à des options “non vérifiées” — mieux vaut demander l’adresse correcte.
• Si le fournisseur a donné un domaine et une IP : testez d’abord le domaine dans « Serveur », puis utilisez l’IP uniquement pour des diagnostics temporaires avant de revenir au domaine.

« ID distant » : clé de la vérification du certificat et cas typiques

« ID distant » est une cause fréquente d’erreurs, car iOS compare cette valeur à celle que le serveur présente lors de l’authentification. Dans les scénarios avec certificat, elle correspond généralement au nom inscrit dans le certificat serveur.

Valeurs typiques pour « ID distant »

• Nom de domaine VPN (exemple : vpn.example.com) — le choix le plus courant et compréhensible.
• Chaîne d’identification (exemple : ikev2.example.com ou gateway-id) — quand le fournisseur différencie l’adresse de connexion du nom inscrit dans le certificat.
• Adresse IP — parfois autorisée mais souvent source de problèmes si le certificat est émis pour un domaine, pas une IP.

Comment diagnostiquer ce qui est attendu

• Regardez ce que votre fournisseur indique dans ses paramètres IKEv2 : parfois « Remote ID » est précisé séparément de « Serveur ».
• Si vous avez un profil de configuration (.mobileconfig) ou un fichier texte du fournisseur, « Remote ID » y est généralement indiqué clairement. En saisie manuelle, reproduisez ces valeurs.
• Si la connexion échoue avec une erreur de confiance/certificat, la cause probable est une discordance entre « ID distant » et le nom dans le certificat.

Mesures sûres (réversibles)

• Si vous avez utilisé une IP en « ID distant », essayez de la remplacer par le domaine fourni par le fournisseur (vous pourrez revenir en arrière si besoin).
• Si « Serveur » est une IP mais que le fournisseur a donné un domaine pour l’identification : gardez l’IP en « Serveur », mais utilisez le domaine exact en « ID distant » pour que la vérification du certificat corresponde.
• Si le fournisseur a donné un « Remote ID » spécifique (une chaîne différente du domaine), utilisez-la telle quelle, même si cela vous semble inhabituel.

« ID local » : quand le laisser vide, quand le remplir explicitement

Le « ID local » représente l’identifiant client présenté au serveur. Dans certaines configurations il est inutile, dans d’autres c’est essentiel (par exemple quand le serveur distingue les utilisateurs ou profils non seulement avec le nom, mais aussi via un identifiant).

Valeurs courantes pour « ID local »

• Vide — souvent suffisant si le serveur se base sur le nom d’utilisateur/mot de passe (EAP) ou un certificat client.
• Nom d’utilisateur — parfois demandé en « ID local », correspondant au login utilisé pour EAP.
• Identifiant spécifique (chaîne) — si le fournisseur attribue un « Local ID » comme client123 ou user@realm.

À vérifier avant modification

• Si le serveur rejette la connexion (pas une erreur de certificat) et que le fournisseur a mentionné un ID local dans ses paramètres, vérifiez que vous n’avez pas laissé ce champ vide.
• Si vous avez plusieurs profils/utilisateurs et que l’un fonctionne mais pas l’autre, comparez la présence ou non de « ID local ».

Mesures sûres (réversibles)

• Si le fournisseur n’a pas fourni d’ID local, commencez par laisser vide. C’est plus facile à corriger et évite les incohérences.
• Si le fournisseur a donné un ID local précis, saisissez-le exactement (majuscules, symboles importants). Si cela ne marche pas, revenez à une valeur vide et demandez leur format exact.

Type d’authentification IKEv2 sur iPhone et son lien avec les ID

Sur iOS, on rencontre généralement deux méthodes d’authentification pour IKEv2 :

• Nom d’utilisateur/mot de passe (EAP) — vous entrez vos identifiants, et le serveur confirme votre identité. Le serveur utilise quasi systématiquement un certificat pour que le client (l’iPhone) vérifie qu’il se connecte au bon serveur. Dans ce mode, remplir correctement l’« ID distant » est capital.
• Certificat — le client possède aussi un certificat (souvent délivré par admin ou fournisseur). L’« ID local » peut alors être important pour choisir le certificat/la politique, mais le comportement dépend du serveur.

Comment savoir quel mode vous utilisez

• Si seul un login/mot de passe vous a été fourni, il s’agit très probablement d’EAP.
• Un fichier .mobileconfig ou certificat seul ne définit pas la méthode : un profil peut contenir des réglages EAP alors que le certificat sert juste à vérifier le serveur. Vérifiez auprès de votre fournisseur la méthode d’authentification prévue.

Mesures sûres (réversibles)

• Ne changez pas le type d’authentification au hasard si votre fournisseur a donné des paramètres pour un mode précis : cela conduit souvent à un rejet de la connexion par le serveur.
• Si vous suspectez une erreur (par exemple, un certificat fourni mais vous essayez d’utiliser login/mot de passe), demandez au fournisseur quel mode est prévu et revenez aux réglages recommandés.

Vérifier la correspondance entre nom du certificat et « ID distant » : checklist

En pratique : quand l’iPhone contrôle le serveur par certificat, « ID distant » doit correspondre au nom que le serveur présente dans son certificat (généralement un nom de domaine). Si ce n’est pas le cas, la connexion ne s’établira pas.

Checklist de diagnostic (sans divulguer de secrets)

Pour un guide pas-à-pas sur comment ajouter un profil IKEv2 sur iOS (où cliquer exactement), consultez la fiche dédiée : configuration IKEv2 VPN sur iOS. Ici nous détaillons seulement le sens des champs et leur vérification.

Petit mémo pour bien gérer les paramètres

• Ne publiez jamais les valeurs « Serveur », « Remote/Local ID », logins, mots de passe, clés ou contenus de certificats sur les chats ou captures d’écran. En cas de besoin, masquez soigneusement les données sensibles.
• Modifiez un paramètre à la fois pour identifier précisément ce qui change et faciliter le retour en arrière.
• Ne désactivez pas la vérification des certificats ni n’acceptez « n’importe quel certificat » pour une connexion rapide : cela affaiblit la protection contre les attaques de type man-in-the-middle.

FAQ : questions fréquentes sur « Serveur », « ID distant » et « ID local »

Peut-on avoir des valeurs différentes pour « Serveur » et « ID distant » ?

Oui, c’est un scénario courant : « Serveur » est l’adresse à laquelle vous vous connectez, et « ID distant » sert à vérifier l’authenticité du serveur. Par exemple, on peut se connecter via une IP mais vérifier le certificat avec un nom de domaine (si le fournisseur l’a précisé ainsi).

Si je n’ai qu’une IP, que mettre en « ID distant » ?

Ça dépend du certificat du serveur et de la configuration VPN. Souvent, le fournisseur donne quand même un domaine ou un identifiant distinct pour « ID distant ». S’il n’y a rien, mieux vaut demander plutôt que de deviner.

Faut-il remplir « ID local » si je me connecte avec un login et un mot de passe ?

Souvent non, ce champ reste vide. Mais certaines configurations exigent un « ID local » explicite (par exemple pour appliquer des politiques). Si on vous l’a donné, utilisez-le ; sinon commencez par laisser vide.

Pourquoi mon VPN ne se connecte plus après un changement de domaine ?

Deux raisons possibles : l’adresse dans « Serveur » a changé (DNS/acheminement) ou le nom dans le certificat ne correspond plus à « ID distant ». La démarche sûre est de revenir aux valeurs précédentes (rollback), puis de demander au fournisseur le nouveau domaine/Remote ID et de s’assurer que le certificat est mis à jour.

Peut-on utiliser le même « ID distant » pour plusieurs serveurs ?

Oui, si l’administrateur a configuré plusieurs passerelles avec la même identité serveur et des certificats compatibles avec ce Remote ID. Dans d’autres cas, les identifiants diffèrent. Suivez les instructions de votre fournisseur pour le serveur choisi.

Quand un serveur personnel peut être utile : si vous avez besoin d’un VPN dédié avec une IP fixe, sans voisins, et des paramètres IKEv2 clairs (y compris les valeurs correctes « Serveur/ID »), c’est plus simple quand votre fournisseur vous donne des identifiants personnels et que vous gérez un seul profil.

Quand cela ne résout pas les problèmes : si les difficultés viennent de valeurs erronées non fournies (comme Remote ID ou certificat) ou de limitations réseau/appareil, un serveur personnel ne remplace pas une configuration correcte et une bonne vérification des certificats — il faut toujours utiliser les données fournies et ne pas affaiblir la sécurité.

Si votre besoin est « un utilisateur — un serveur », vpn.how propose un serveur VPN personnel avec IP dédiée ; consultez leur site et espace client pour les localisations, protocoles, tarifs et limites actuels.