iPhone IKEv2 vers RouterOS : quel identifiant va où
Quatre affirmations distinctes décident d'un tunnel IKEv2 sous iOS : l'adresse composée, l'identité de serveur attendue, l'identité client revendiquée et le matériel de certificat.
Atteindre la passerelle MikroTik ne règle que la moitié transport d'un déploiement IKEv2, et rien d'autre. Ensuite, quatre affirmations distinctes décident si le tunnel se forme : l'adresse que le téléphone compose, l'identité de serveur qu'il attend, l'identité qu'il revendique pour lui-même et le matériel de certificat qui étaye cette revendication. Vérifiez-les dans cet ordre et arrêtez-vous à la première qui ne correspond pas à ce que la passerelle présente. Chacune se modifie à un endroit différent, et c'est pourquoi une modification erronée déplace généralement la panne au lieu de la corriger.
| Setting | What it decides | What it has to agree with |
|---|---|---|
| Remote address | where IKE packets are sent | a reachable name or address for the gateway |
| Remote Identifier | which server identity is expected | the gateway certificate name and the peer identity RouterOS presents |
| Local Identifier | who the phone claims to be | the client certificate name and the RouterOS identity entry |
| Certificate payload | trust plus proof of key possession | the issuing chain and a usable client private key |
Vérifiez les champs du profil dans l'ordre où l'échange les utilise
L'adresse distante est la destination du premier paquet IKE et rien de plus. L'identifiant distant est ce que le téléphone attend que la passerelle prouve être, et c'est un nom, pas une route. Remplir les deux avec le même nom d'hôte fonctionne quand le certificat de la passerelle porte ce nom, et échoue d'une manière qui ressemble à un problème de routage quand ce n'est pas le cas. Lisez le profil comme une suite d'affirmations, et non comme une liste de champs à remplir.
L'identifiant local est la revendication du téléphone lui-même, et il doit être un nom que l'entrée d'identité de RouterOS accepte pour le certificat client que le téléphone présente. Si les deux ne concordent pas, la passerelle rejette la connexion après la validation du certificat lui-même, et le journal ressemble à un problème d'autorisation plutôt qu'à un problème de nommage.
Vérifiez les identifiants par rapport à ce que la passerelle présente
Une entrée de pair RouterOS configurée pour l'authentification par certificat présente son propre certificat, et son identité est tirée de ce certificat sauf si vous avez configuré autre chose. Si l'identifiant distant du téléphone nomme le nom DNS de la passerelle, le certificat de la passerelle doit porter ce nom à un endroit que le téléphone acceptera, typiquement un nom alternatif du sujet. Un certificat émis pour un autre nom commun ne validera pas, même si la clé et la chaîne sont parfaites.
Les profils Apple gérés peuvent aussi porter une contrainte de nom de certificat évaluée en plus des champs d'identifiant. Inspectez la charge utile plutôt que de déduire le nom de validation de ce qu'affiche l'écran des réglages, car les deux ne sont pas le même réglage.
Vérifiez que le certificat client est une clé, pas seulement une ancre de confiance
Importer un certificat d'AC donne au téléphone de quoi valider la passerelle. Cela ne lui donne pas une identité client, et l'authentification par certificat exige le certificat feuille client et sa clé privée livrés ensemble par le chemin d'enrôlement approuvé. Un PKCS#12 construit sans la clé privée produit un profil qui s'installe proprement et n'authentifie rien.
La feuille client a aussi besoin d'une identité qu'attend le côté RouterOS, ce qui signifie que le sujet ou le nom alternatif du sujet doit correspondre à la configuration d'identité correspondante. Émettre les certificats client et serveur depuis une même AC rend la chaîne commode et ne rend pas les deux feuilles interchangeables.
Vérifiez que la politique RouterOS accepte ce nom
Sur la passerelle, l'entrée de pair fixe le mode d'échange et la méthode d'authentification, et l'entrée d'identité lie l'identité distante acceptée à un certificat et à la politique qui suit. Dans RouterOS v7, ce couplage s'exprime par les entrées de pair et d'identité IPsec, par exemple un pair IKEv2 avec auth-method=digital-signature. Vérifiez le contenu réel du menu de votre version installée, et non un guide écrit pour une version plus ancienne.
C'est aussi là qu'une incohérence est la moins coûteuse à corriger, car la passerelle peut vous indiquer à la fois l'identité reçue et l'identité souhaitée. Élargir l'identité acceptée pour faire taire l'erreur supprime le lien qui donnait son sens au déploiement.
Vérifiez quelle étape a échoué avant de modifier quoi que ce soit
Lisez la tentative aux deux extrémités et classez-la avant de changer une proposition. Une incohérence de proposition, une clé de signature manquante, un émetteur non fiable, un identifiant de pair erroné et une autorisation client refusée ressemblent toutes à un tunnel mort vu du téléphone, et chacune a un responsable différent. Changer les cinq réglages à la fois garantit que vous n'apprendrez rien du résultat.
Consignez l'identité présentée, l'identité attendue, l'émetteur et le numéro de série du certificat ainsi que le nom de la politique concernée, en gardant les clés privées et les secrets de profil hors de ce relevé. Une fois l'authentification réussie, testez un service privé et sa réponse, car l'attribution d'adresses, les sélecteurs, le DNS et la politique d'accès doivent encore fonctionner après la fin de l'échange IKE.