Deux identités dans une connexion IKEv2 : d'abord la machine, ensuite l'utilisateur

Un certificat client est validé, le premier échange aboutit, puis la connexion s'arrête sur une erreur concernant une passe d'authentification supplémentaire. Rien dans la chaîne de certificats n'est faux et rien n'a changé sur le réseau. La passerelle est configurée pour exiger une seconde preuve du côté qui se connecte, et le client n'en envoie jamais. Décider qui prouve quoi, et dans quel ordre, est toute la tâche, et cela commence par lire la stratégie depuis l'extrémité où vous vous tenez. Deux preuves de natures différentes, dans un ordre fixe, relèvent d'une décision de conception et non d'une case à cocher.

Le symptôme : un échec après une première preuve réussie

Le premier échange aboutit et le journal semble sain, jusqu'à ce que la passerelle demande une identité d'utilisateur via EAP. La poignée de main s'arrête alors ou renvoie une erreur de protocole nommant la passe supplémentaire. Un certificat de machine parfaitement valide est rejeté pour une raison qui n'a rien à voir avec sa validité. La stratégie demandait une seconde preuve, et la réponse du client n'est jamais arrivée.

Les deux descriptions de cet échec sont exactes selon l'endroit où vous vous tenez. Du côté du client, cela ressemble à un serveur qui rejette un certificat valide, et du côté du serveur à un client qui ne peut pas terminer la connexion. Le même événement se lit comme un problème de confiance dans un journal et un problème de capacité dans l'autre. Seule la stratégie configurée vous dit lequel c'est.

Ce que l'extension ajoute, et ce qu'elle n'ajoute pas

IKEv2 transporte une extension permettant plusieurs échanges d'authentification dans une seule session. RFC 4739 esquisse, entre autres séquences, un client qui prouve une identité par certificat puis authentifie une personne via EAP. Le document est de statut Experimental, ce qui signifie qu'aucune implémentation ne vous doit cette fonction. Ne présumez rien du support avant que le pair ne le négocie.

Les deux côtés doivent prendre en charge l'extension et s'accorder sur elle pendant l'échange. Une passerelle configurée pour une seconde passe ne peut pas forcer un client à en faire une, et un client qui la prend en charge ne l'utilisera pas si le serveur ne le demande pas. C'est cette asymétrie qui fait que l'échec se manifeste généralement par un délai dépassé ou une erreur de protocole plutôt que par une déclaration claire sur la capacité. Lire la configuration d'un seul côté vous dit la moitié de ce qui va se passer.

Une preuve par extrémité est la forme normale, et ce n'est pas cette conception. La passerelle présente son certificat, l'utilisateur répond par EAP, et chaque côté a authentifié l'autre exactement une fois. Ces deux preuves viennent d'extrémités opposées, donc aucune ne dit quoi que ce soit de distinct sur la machine et la personne qui l'utilise.

EAP-TLS est une troisième forme, et ce n'est pas celle-ci non plus. Là, un certificat client est présenté à l'intérieur d'une méthode EAP, donc le client termine tout de même une seule authentification IKE. Les identifiants peuvent sembler identiques au cas à plusieurs passes alors que le protocole transporte une passe au lieu de deux. C'est pourquoi une conception copiée d'un déploiement EAP-TLS échoue précisément là où la seconde preuve est attendue.

Le même fichier se lit différemment sur la passerelle

Le même fichier swanctl se lit différemment selon l'endroit où il s'exécute, et c'est la partie qui fait trébucher les gens. Sur l'ordinateur portable, la passerelle est le pair, et sur la passerelle, c'est l'ordinateur portable, donc écrivez le côté local comme qui je suis et le côté remote comme qui j'accepterai. Un bloc local décrit comment cette extrémité s'authentifie, et un bloc remote indique ce qu'il exige de l'autre extrémité. Copier un bloc entre les deux fichiers en inverse le sens sans changer un seul caractère. Comparer les deux fichiers ne vous apprend presque rien, car les mêmes mots y signifient des choses opposées.

La position d'une section fixe son ordre, sauf si un numéro de passe la supplante. Les sections local ou remote supplémentaires décrivent donc des passes supplémentaires et non des alternatives, et le numéro de passe explicite dans la référence de swanctl.conf existe précisément pour rendre cet ordre délibéré. Sans lui, déplacer un bloc change le comportement. C'est aussi pourquoi deux configurations qui semblent équivalentes sur le papier peuvent se comporter dans un ordre opposé.

Cette règle d'ordre produit le mode de défaillance qu'il vaut la peine de retenir. Un second bloc remote n'est pas une autre option acceptable ; c'est une seconde exigence, et c'est pourquoi une stratégie qui se lit comme ou/ou se comporte comme et-puis. Une stratégie de passerelle peut accepter le certificat de la machine inscrite puis exiger l'échange EAP de cet utilisateur, dans cet ordre.

Distinguez les passes des facteurs indépendants

Deux passes ne sont pas automatiquement deux facteurs indépendants. Répéter une preuve, ou détenir deux identifiants dans le même magasin, n'apporte pas la force que la conception était censée ajouter. L'indépendance est une propriété de la manière dont les secrets sont détenus et de ce qui les compromet, non du nombre d'échanges exécutés par le protocole. Une conception qui compte les passes comme des facteurs surestime ce qu'elle a. Cette distinction compte surtout lorsqu'une question de conformité demande combien de facteurs la connexion utilise réellement.

Un certificat de machine prouve la possession de sa clé acceptée, et rien de plus. Ce n'est ni une attestation matérielle ni un rapport de santé de l'appareil, donc une stratégie qui a besoin d'informations de posture a besoin d'un autre mécanisme. Le champ subject n'est pas non plus une étiquette d'inventaire fiable, car le subject est choisi par celui qui a émis ou enrôlé le certificat. Si la conception a besoin de la preuve que la machine est saine, cette preuve doit venir d'un composant qui mesure la machine.

Notez ce que chaque passe prouve réellement avant de l'ajouter. Quand deux passes prouvent deux fois la même chose, la seconde ajoute de la latence et des tickets de support plutôt que de l'assurance. Cette note est aussi ce qui arrête un débat sur la question de savoir si la passe supplémentaire vaut son coût.

Écrivez la règle d'appariement et testez les refus

Décidez quelles identités de machine peuvent s'apparier avec quelles personnes, et écrivez la règle là où vit l'application. Deux identifiants valides côte à côte ne prouvent rien sur l'appariement, car l'appariement est une décision d'autorisation et non un résultat d'authentification. Les enregistrements d'inscription ou le backend d'authentification doivent appliquer la relation que l'organisation veut.

Testez ensuite ce qui devrait échouer : un utilisateur accepté sur une machine non approuvée, un utilisateur non approuvé détenant l'identifiant de la machine, et un pair incapable d'exécuter la passe supplémentaire. Si les trois reçoivent silencieusement le même accès, la stratégie décrit une intention au lieu de l'appliquer. Comparez la configuration déclarée avec ce que le démon rapporte, car une connexion qui n'a jamais correspondu ressemble à une règle qui a passé :

swanctl --list-conns
swanctl --list-sas

Vérifiez les passes négociées et l'autorisation qui en résulte, pas seulement la connexion réussie. Et ne vous rabattez pas sur d'anciens réglages IKEv1 XAuth comme raccourci : faites correspondre le protocole, les rôles, l'ordre et le comportement réel du client au lieu de supprimer une passe requise jusqu'à ce qu'une connexion réussisse. Supprimer la passe qui échoue est la façon dont une conception à deux preuves devient discrètement une conception à une preuve que personne n'a relue. Gardez la suppression dans le journal des changements.