iOS a rejeté votre tunnel strongSwan : comparez les propositions IKE

Rien dans le certificat ni dans l'adresse n'explique pourquoi un iPhone qui se connectait à strongSwan l'an dernier échoue cette année. Rien dans l'adresse, la clé pré-partagée ou l'identité du client n'a eu besoin de changer. Ce qui a bougé, c'est la liste des transformations que le client intégré du téléphone accepte de négocier, et dès que cette liste cesse de recouper celle du serveur, l'échange se termine avant que l'identité de quiconque soit examinée.

La ligne de journal qui tranche

Montez le niveau de journalisation de cette connexion et trouvez les deux entrées qui décident du résultat : ce que le téléphone a proposé et ce que le serveur a choisi. Si le journal se termine sans proposition sélectionnée et signale que rien n'a correspondu, l'authentification n'a jamais été tentée. Un certificat neuf et un mot de passe neuf n'y changent rien, car les deux se consomment plus tard. Ni l'un ni l'autre ne peut influer sur un résultat décidé avant l'examen de l'identité.

Séparez les deux formes de panne avant de modifier quoi que ce soit. Aucune modification des transformations ne sauve des identifiants rejetés, et aucune correction des identifiants ne sauve une transformation rejetée. L'entrée de journal qui nomme une proposition sélectionnée vous dit dans laquelle des deux vous êtes. Sans cette entrée, vous devinez.

La ligne sélectionnée nomme la proposition par son jeu de transformations plutôt que par une étiquette conviviale. Comparez les champs de chiffrement, d'intégrité et de groupe de cette ligne avec la liste envoyée par le téléphone, car une divergence sur un seul champ suffit à perdre.

Ce qui a changé sur le téléphone

Une version d'iOS a rogné les algorithmes que son client accepte d'utiliser. Les hachages d'intégrité faibles, les petits groupes Diffie-Hellman et les propositions qui listent d'abord les options héritées ont cessé d'être acceptables.

Les listes plus longues ne sont pas plus sûres ici. La sélection suit l'ensemble accepté du téléphone et son propre ordre de préférence, si bien qu'un serveur qui annonce un catalogue large peut encore perdre la négociation quand les entrées modernes ne sont pas celles qui sont retenues. Préférez une liste courte avec les entrées modernes en tête. Une liste longue qui s'ouvre sur des options héritées invite exactement la panne que vous cherchez à éviter. L'ensemble accepté est une contrainte extérieure qui bouge à chaque mise à jour du client, donc une configuration qui marchait hier est une preuve sur hier.

Une paire qui négocie encore

Pour les téléphones actuels, une seule combinaison moderne suffit. Une paire qui négocie ressemble à ceci :

ike=aes256-sha2_256-modp2048
esp=aes256-sha2_256

La ligne ike porte le chiffrement, l'intégrité et le groupe Diffie-Hellman utilisés pendant l'échange de clés. La ligne esp ne couvre que le canal de données, car le groupe a été fixé avant qu'elle ne s'applique. Rechargez la connexion ou redémarrez le démon, puis reconnectez le téléphone. Ne gardez cette valeur de groupe que si chaque client que vous servez l'accepte encore, et n'élargissez pas la proposition pour tout le monde parce qu'un vieux pair en a besoin de plus.

Trois endroits pour corriger, un seul est généralement fermé

• Une proposition moderne pour chaque pair. Correct quand tous les clients sont des téléphones et des postes actuels. Elle supprime les transformations anciennes au lieu de négocier autour d'elles.
• Une seconde définition de connexion pour les clients Apple. Maintient un vieux pair en vie tout en donnant au téléphone une proposition qu'il accepte. Cela coûte un bloc de connexion de plus et rend l'exception visible.
• Changer le client. Rarement à votre portée : quand un système de gestion ou une application distribue le profil, il n'y a pas d'éditeur de propositions à toucher, et le client intégré n'en expose aucun.

Choisissez la seconde option quand un appareil hors de votre contrôle ne peut pas être mis à jour. Choisissez la première quand vous pouvez mettre le vieux pair au rebut et préférez porter une seule politique.

Dans les deux cas, le choix est visible dans la configuration, et c'est tout l'intérêt. Un repli silencieux qui négocie à la baisse jusqu'à une transformation ancienne est pire qu'un bloc explicite, car aucune revue ne le fera jamais surface.

Prouvez-le, puis consignez-le

Reconnectez-vous et vérifiez trois faits distincts sur le serveur : une proposition a été sélectionnée, la connexion apparaît comme établie et le client a reçu une adresse. Une poignée de main établie sans adresse distante désigne le pool ou les sélecteurs de trafic, et cela relève d'un changement séparé. Traiter les deux ensemble fait passer une négociation résolue pour non résolue.

Notez le jeu de transformations accepté, quand vous l'avez modifié et quelle version du client vous avez vérifiée. La prochaine mise à jour peut déplacer à nouveau l'exigence, et les valeurs qui ont marché sont la première chose que vous voudrez avoir à côté des nouvelles.