Planifier des réglages IKEv2 adaptés à plusieurs clients

Un profil qui fonctionne sur un seul poste est un test réussi pour un seul client. Ce n’est pas un déploiement multiplateforme, et le traiter comme tel produit le schéma de support bien connu : Windows se connecte, le téléphone échoue au contrôle d’identité, et l’ordinateur portable géré se reconnecte à chaque réveil. Les différences sont réelles et largement prévisibles, c’est pourquoi le plan doit être une matrice et non une capture d’écran.

Décidez d’abord du contrat d’identité

Documentez l’identité du serveur, la confiance dans le certificat et la méthode d’authentification du client avant de parler d’algorithmes. Ces trois éléments décident si un client peut s’authentifier, et ce sont les parties que les plateformes expriment différemment.

Vérifiez comment chaque plateforme nomme l’identifiant attendu et comment elle traite les autres noms du sujet. Un profil qui accepte un nom de serveur sur un client peut rejeter le même certificat sur un autre, car le champ d’identifiant est rempli à partir d’une valeur différente.

Choisissez ensuite l’intersection cryptographique

Comparez les propositions que chaque client pris en charge peut offrir et choisissez une intersection moderne que la passerelle autorise aussi. N’activez pas une liste héritée surdimensionnée pour qu’un vieil appareil se connecte, car cette liste devient la valeur par défaut de la passerelle pour tous ceux qui suivent. Notez pourquoi chaque option héritée est encore là. Si personne ne peut nommer l’appareil qui en a besoin, ce n’est pas une exigence.

Gardez les réglages IKE et CHILD distincts dans le plan. Une proposition acceptable pour l’échange IKE n’est pas automatiquement acceptable pour le trafic protégé, et les deux se négocient séparément. Une passerelle qui accepte une proposition à une couche peut encore la refuser à l’autre, et le journal montrera un échec qui donne l’impression que la première couche a réussi.

Fournissez les identifiants via un processus vérifié et gardez un mot de passe utilisateur, un secret partagé et une clé privée de client dans leurs propres champs. Les essais et erreurs sur des boîtes aux noms similaires sont la manière dont un test qui fonctionne devient impossible à reproduire.

Testez le cycle de vie, pas l’état stable

Pour chaque client, testez l’authentification initiale, l’application prévue, la résolution DNS et la couverture des familles d’adresses. Exercez ensuite les parties qui n’apparaissent que plus tard : le renouvellement, la veille et un changement de réseau normal.

La prise en charge de MOBIKE et le comportement de réauthentification peuvent différer du résultat stable que vous venez de mesurer. Consignez l’événement et l’état de l’association à ce moment-là, et pas seulement si l’interface finit par sembler connectée.

Définissez ce que le trafic direct peut faire lorsque le VPN n’est pas disponible. C’est une décision de politique distincte de la reconnexion du client, et la plupart des déploiements répondent à la seconde question en ignorant la première. Écrivez la réponse dans les notes de déploiement à côté des noms de profils. Quelqu’un en aura besoin pendant une panne et n’aura pas le temps de la reconstituer.

Utilisez des contrôles d’identité du serveur quand une plateforme n’est pas d’accord

Lorsqu’un profil fonctionne sur une plateforme et qu’une autre rejette son nom, comparez l’identifiant que le client a réellement envoyé aux identifiants que porte le certificat. Cette comparaison résout la plupart de ces cas plus vite que le changement des listes de chiffrement.

Conservez la matrice testée avec la source de configuration et la procédure de mise à jour. Lorsque la prise en charge d’un ancien client se termine, retirez son exception délibérément au lieu de laisser des réglages de compatibilité plus faibles cachés dans la passerelle pour que le prochain audit les trouve. La documentation IKEv2 de strongSwan est une référence utile sur la façon dont les échanges se configurent.