Remote ID du VPN sur iPhone : ce que ce champ signifie vraiment
Remote ID est l’identité que le serveur doit prouver à votre iPhone ; Local ID est l’identité que le client revendique. Voici quelle chaîne va dans quel champ.
Vous êtes dans Réglages, en train d’ajouter une configuration IKEv2, et deux champs demandent un texte que personne ne vous a donné : Remote ID et Local ID. Aucun des deux n’est votre nom d’utilisateur, et aucun n’est une seconde copie du champ Serveur. Remote ID est l’identité que la passerelle doit prouver à votre iPhone ; Local ID est l’identité que votre iPhone revendique auprès de la passerelle. Trompez-vous sur l’un ou l’autre et le tunnel meurt après que le serveur a déjà répondu : c’est pourquoi l’échec ressemble à un problème de mot de passe sans en être un.
Où se trouvent les champs dans iOS
Ouvrez Réglages > Général > VPN et gestion de l’appareil > VPN et ajoutez une configuration IKEv2. Sous Authentification, vous choisissez Nom d’utilisateur ou Certificat, et c’est seulement alors que Remote ID et Local ID apparaissent comme des zones de texte libre. Ce sont des identifiants, pas des adresses : iOS les transporte dans l’échange IKE_AUTH, où IKEv2 nomme l’identité de l’initiateur IDi et celle du répondeur IDr.
Après l’enregistrement, iOS replie la configuration en une seule ligne et cesse d’afficher les valeurs. Touchez le bouton d’information ou rouvrez le profil avant de conclure que les champs sont vides. Une configuration poussée par MDM peut les griser complètement, ce qui change qui peut corriger le problème.
Remote ID est le nom de la passerelle
C’est la valeur que votre iPhone attend que le serveur prouve. Avec l’authentification par certificat, elle est comparée au nom figurant dans le certificat du serveur, généralement le subject ou une entrée subjectAltName. Si le certificat est émis pour vpn.example.com, ce nom d’hôte est le Remote ID, même lorsque vous atteignez la machine par une adresse IP nue.
Ce décalage est l’échec classique : les paquets arrivent, le serveur répond, et la connexion s’effondre quand même parce que l’identité du certificat ne correspond pas à ce que le profil exigeait. Pointer le champ Serveur vers l’IP brute n’aide pas, et sur beaucoup de passerelles le serveur cesse simplement de répondre à une identité qu’il ne peut pas apparier.
La passerelle possède un réglage correspondant. Un serveur strongSwan envoie sa propre identité avec leftid et peut restreindre l’identité du client avec rightid ; si les deux côtés ne sont pas d’accord sur la chaîne, IKE_AUTH échoue dans les deux sens. Demandez à l’exploitant pour quelle identité le certificat a été émis au lieu de recopier l’URL depuis la barre du navigateur.
Apple documente les clés de la charge utile sous les noms RemoteIdentifier et LocalIdentifier dans sa référence des réglages IKEv2. Les deux sont de simples chaînes, donc la casse et un espace final peuvent compter.
Local ID est ce que revendique votre iPhone
Avec l’authentification par nom d’utilisateur, EAP vérifie le nom et le mot de passe, et Local ID est une identité IKE distincte que certaines passerelles imposent aussi. Une passerelle peut exiger que Local ID soit égal au nom d’utilisateur, soit une adresse électronique ou corresponde à une entrée de sa politique de connexion ; d’autres l’ignorent. Le laisser vide n’est sûr que lorsque l’exploitant le dit.
Avec l’authentification par certificat, Local ID doit correspondre à une identité que la passerelle accepte pour ce certificat client, souvent le nom commun du certificat ou une valeur associée à un enregistrement d’appareil. Copier le profil d’un collègue copie aussi son identité. Au mieux la passerelle journalise le mauvais appareil ; au pire une politique par appareil vous refuse.
Le piège est de supposer que vide signifie aucune identité. Ne remplissez pas un champ vide avec votre adresse électronique simplement parce qu’il semble inachevé. Confirmez la valeur voulue et saisissez-la exactement telle qu’elle a été donnée.
Une vérification de cinq minutes avant d’enregistrer
Passez-les dans l’ordre ; la première étape qui échoue est celle à corriger.
- Obtenez trois chaînes auprès de l’exploitant : le nom dans le certificat du serveur, le Local ID attendu et la méthode d’authentification.
- Faites correspondre la méthode d’authentification. Remote ID et Local ID ne remplacent pas un nom d’utilisateur et un mot de passe, et un profil de certificat n’acceptera pas de mot de passe.
- Saisissez les valeurs exactement, majuscules et minuscules comprises, sans espace final.
- Laissez la validation des certificats active. Installer un certificat racine sans rapport pour faire taire un avertissement masque un décalage de nom au lieu de le corriger.
- Testez en données mobiles, pas sur le Wi-Fi du bureau, pour qu’un portail captif ou un DNS fractionné ne se fasse pas passer pour un problème d’identité.
| Field | What belongs there | What a wrong value looks like |
|---|---|---|
| Remote ID | The DNS name in the gateway certificate | Server answers, then the tunnel drops with a certificate or identity error |
| Local ID | The identity the gateway policy expects for you | IKE_AUTH or user authentication fails after the server responds |
| Server | A reachable hostname or IP | Timeout with no identity exchange at all |
Lisez le tableau de haut en bas. Un délai dépassé sur la ligne Serveur signifie que les champs d’identité n’ont jamais été testés : arrêtez-vous là. Une erreur qui n’apparaît qu’après la réponse du serveur est presque toujours un décalage de Remote ID ou de Local ID.
Des erreurs qui désignent le mauvais champ
Un message comme "User authentication failed" concerne les identifiants ou EAP, pas Remote ID. Un avertissement de certificat concerne le nom dans le certificat, et c’est là que Remote ID et le champ Serveur se rencontrent. "The VPN server did not respond" signifie généralement que UDP 500 et 4500 n’ont jamais abouti, ou que le traversal NAT a échoué, et qu’aucune identité n’a été comparée.
Côté passerelle, les échecs d’identité se présentent autrement : le pair est rejeté pendant IKE_AUTH, ou le journal nomme l’ID envoyé par le client et indique qu’il ne correspond à aucune connexion. Cette ligne de journal est le moyen le plus rapide de trancher, car elle montre la chaîne exacte envoyée par le téléphone.
Réinitialiser un mot de passe ne réparera pas une identité de serveur attendue, et changer Remote ID ne réparera pas un mauvais mot de passe. Séparez d’abord l’étape, puis modifiez le champ qui appartient à cette étape.
Quand le profil est géré
Si les champs sont grisés, la configuration vient de MDM et le téléphone n’est pas l’endroit pour la corriger. La charge utile VPN porte les identifiants, donc la bonne modification se fait dans le profil sur le serveur de gestion, suivie de sa réinstallation sur l’appareil.
Vérifiez dans Réglages > Général > VPN et gestion de l’appareil si le profil est géré et qui l’a signé. Si vous ne pouvez pas le supprimer, vous ne pouvez pas modifier les identifiants localement, et créer un second profil local ne fait que créer une configuration conflictuelle.
Avant de fermer Réglages, notez les trois chaînes que vous avez saisies et leur origine. La prochaine fois que le tunnel échoue, comparez l’ID reçu dans le journal de la passerelle à cette note : s’il diffère, vous regardez le champ, pas le mot de passe.