iOS IKEv2 vers strongSwan : aucune proposition choisie, corrigez la liste

L'iPhone monte le tunnel, la passerelle répond par rien, et le téléphone affiche une erreur générique. Le journal de strongSwan est plus précis : aucune proposition choisie. Ce message signifie que les deux listes de suites de chiffrement acceptables ne se sont jamais chevauchées, donc l'échange s'est terminé avant le début de l'authentification. C'est un problème de correspondance, et la solution est de faire se croiser les listes.

Où la passerelle énonce sa politique

strongSwan écrit sa politique dans la configuration, et le point d'exclamation final décide de la façon dont cette politique est lue. Avec le signe, la liste est exhaustive : ces entrées et rien d'autre seront acceptées. Sans lui, la même ligne est un ordre de préférence, et le démon peut choisir quelque chose que vous n'aviez pas prévu. Demandez quelle forme est déployée avant de traduire quoi que ce soit, car les deux se comportent différemment face au même client. Notez la ligne exacte, signe compris, et testez contre elle.

Un client qui offre une liste plus large peut toujours se connecter à une passerelle épinglée, tant qu'une combinaison apparaît des deux côtés. Ce qui ne peut pas arriver, c'est une négociation hors de l'ensemble épinglé.

C'est pourquoi un profil copié d'une autre application VPN peut fonctionner là où le vôtre ne fonctionne pas : l'autre application livrait une liste différente.

Les noms doivent correspondre, pas s'améliorer

Deux traductions piègent ceux qui déplacent des valeurs de strongSwan vers iOS. L'algorithme d'intégrité écrit SHA1 dans une proposition IKE voyage sous sa forme tronquée, qu'iOS nomme .SHA96. Le groupe Diffie-Hellman écrit modp1024 est group 2, qu'iOS nomme .group2. Le remplacement par SHA-256 ou group 14 ne négociera pas contre une passerelle qui n'accepte que l'ancienne paire. Le client doit décrire le même algorithme, pas un plus fort.

Définissez ces valeurs explicitement dans NEVPNProtocolIKEv2. Les valeurs par défaut peuvent être plus larges ou plus étroites que le profil que vous remplacez, et la différence n'apparaît que lorsque la poignée de main échoue.

La proposition enfant échoue plus tard et plus discrètement

Configurez l'association de sécurité enfant en plus de celle d'IKE. Quand seuls les paramètres IKE correspondent, le tunnel s'authentifie puis ne transporte aucun trafic, ce qui est un échec bien plus discret qu'un refus. Définissez le chiffrement, l'intégrité, le groupe et la durée de vie de l'enfant dans la même passe. Gardez la durée de vie du client à la valeur de la passerelle ou en dessous, car insister sur une plus longue produit le même message d'aucune proposition choisie pour une autre cause. Une incompatibilité là-bas ressemble à une incompatibilité IKE dans le journal.

Vérifiez si le profil s'authentifie par certificats ou par secret partagé pendant que vous êtes dans la configuration. Un rejet de proposition et un rejet d'authentification apparaissent sur des lignes différentes, et corriger le mauvais coûte une journée. Testez avec une connexion neuve après chaque changement, une variable à la fois, car l'état mis en cache cache lequel a bougé.

Ne gardez l'ancienne suite que tant qu'elle est nécessaire

Épingler SHA-1 avec un groupe de 1024 bits est un pont, pas une destination. Les deux sont obsolètes, et les clients plus récents peuvent les refuser d'emblée, ce qui signifie que le profil échouera sur l'appareil suivant sans aucun changement de votre côté. Traitez l'épinglage comme temporaire et dites-le dans l'enregistrement.

Si strongSwan est à vous, ajoutez une proposition moderne et laissez les deux extrémités négocier vers le haut pendant que l'entrée ancienne reste pour les appareils plus anciens. Lisez la sortie d'état du démon pour voir quelle suite chaque connexion a réellement utilisée. Retirez ensuite l'épinglage côté client une fois la paire moderne confirmée. Un tunnel qui monte n'est pas une preuve suffisante, car il peut monter sur la suite que vous cherchiez à retirer. La documentation IKEv2 de strongSwan décrit la syntaxe des propositions et le marqueur strict.