IKEv2 adresse du serveur vs identité : ce que le client vérifie réellement

Une passerelle qui change d'adresse peut continuer à fonctionner tandis que la même passerelle derrière un nouveau certificat s'arrête, et l'inverse se produit également. L'adresse indique au client où envoyer les paquets ; l'identité authentifiée indique au client si l'homologue qui répond est celui en qui il doit faire confiance. IKEv2 les conserve sous forme de deux champs distincts, ce qui est utile une fois que vous arrêtez de les traiter comme une seule chaîne. Ils sont également configurés à différents endroits, de sorte que l’un peut être correct tandis que l’autre a tort.

Vérifiez-les dans cet ordre et arrêtez-vous à la première incohérence, car les vérifications ultérieures supposent que les précédentes ont réussi.

Tout d'abord, quelle valeur est l'adresse

L'adresse de connexion est celle que le client compose : une adresse IP, un nom DNS qui se résout en un, ou un frontal à charge équilibrée. Ce sont des informations sur les transports et rien de plus. L'identité est incluse dans la charge utile de l'ID IKEv2 et est ensuite comparée au certificat de l'homologue. Un nom DNS dans la zone d'adresse ne devient pas l'identité attendue, et une adresse IP brute ne devient pas l'identité simplement parce que le socket y est connecté.

En termes strongSwan, l'adresse est right ou left, et l'identité attendue est rightid ou leftid, et c'est ce que décrit la documentation de configuration IKEv2. Si vous n'avez modifié que l'adresse, vous avez configuré la moitié de la paire.

Deuxièmement, ce que le certificat peut prouver

L'identité a un type et le certificat doit porter un nom correspondant. Une identité DNS est satisfaite par une entrée dNSName dans l'extension du nom alternatif du sujet ; une identité IP nécessite une entrée iPAddress. Un certificat délivré pour vpn.example.com ne prouve rien sur l'adresse littérale 203.0.113.10, et un certificat délivré pour cette adresse ne prouve rien sur le nom. La réémission pour un nom différent n'est donc pas un remplacement immédiat, même lorsque la même clé et CA sont réutilisés.

Les clients modernes ignorent le nom commun lorsqu'un autre nom de sujet existe, et beaucoup l'ignorent complètement. Si la liste SAN ne contient pas la valeur vérifiée par le client, la négociation échoue une fois que le certificat a déjà été accepté comme digne de confiance, c'est pourquoi le journal se lit comme une erreur d'identité plutôt que comme une erreur de confiance.

Troisièmement, comment chaque client énonce ses attentes

Windows prend le nom ou l'adresse du serveur que vous avez saisi et nécessite que le certificat y corresponde, donc la saisie d'une adresse IP crée une attente IP. Le client IKEv2 de Android se comporte de la même manière et tous deux rejettent un certificat valide et publiquement approuvé qui nomme un hôte différent. Un profil peut commencer à échouer simplement parce que quelqu'un a remplacé le nom d'hôte par son adresse lors d'une migration. Regardez ce que le client a demandé avant de regarder ce que contient le certificat.

Sur strongSwan, l'attente est explicite : définissez rightid sur l'identité que le serveur présente réellement, qui peut différer de la droite. Le définir sur %any accepte tout ce que propose le homologue et supprime exactement le chèque que vous essayez de conserver.

Quatrièmement, séparez la connexion de l'utilisateur de l'identité des pairs

L'authentification EAP et l'identité du serveur répondent à des questions différentes. Une identité EAP telle que [email protected] indique qui est l'utilisateur, une fois que le client a décidé que le serveur est le bon. La rotation de ce mot de passe ne peut pas corriger une incompatibilité d’identité de homologue, car la connexion n’atteint jamais l’étape de connexion de l’utilisateur.

Un rapport nettoyé doit nommer à la fois : l'identité attendue par le client, l'identité présentée par le serveur et les entrées SAN du certificat.

Cinquièmement, changez-le via un canal vérifié

Lorsque la passerelle se déplace légitimement, mettez d'abord à jour l'adresse et laissez l'identité tranquille, car c'est le cas que IKEv2 gère bien. Lorsque l'identité elle-même change, traitez-la comme un événement de confiance et obtenez la nouvelle valeur d'une source à laquelle vous faites déjà confiance, et non du point de terminaison en panne actuellement. Un message transmis via la connexion que vous essayez de valider ne constitue pas une preuve de cette connexion.

Enregistrez ensemble l’adresse finale, l’identité et la liste SAN dans les notes de profil. La prochaine personne qui touchera le certificat verra alors lequel des trois est autorisé à se déplacer.