Quand IKEv2 renvoie TS_UNACCEPTABLE, comparez les vrais sous-réseaux

Lisez TS_UNACCEPTABLE comme un désaccord de couverture, pas comme un profil corrompu. La passerelle dit que les deux pairs n'ont pas pu s'entendre sur les adresses que ce tunnel peut transporter. L'IKE SA peut déjà être établie à ce moment-là, et c'est pourquoi un client peut sembler connecté sans aucune SA enfant derrière lui. Une fois formulé ainsi, le travail devient mécanique. Notez les préfixes prévus des deux côtés, comparez-les dans un seul sens et resserrez jusqu'à ce qu'ils se recoupent.

Notez d'abord les paires prévues

Avant de toucher à la configuration, listez quatre valeurs : la plage source de l'initiateur, sa plage de destination et la même paire vue du répondeur. Notez aussi la famille d'adresses de chacune. Une plage IPv4 et une plage IPv6 sont des types de sélecteurs différents, et aucune ne peut être repliée dans la charge utile de l'autre.

Ajoutez toute restriction de protocole ou de port que porte la politique. Une règle qui n'autorise que TCP 445 vers un serveur de fichiers décrit un ensemble plus étroit que le sous-réseau où elle se trouve. Si vous l'omettez de vos notes, le résultat de la négociation paraîtra incohérent pour des raisons que vous ne voyez pas.

Inversez les étiquettes avant de les comparer

Local et distant sont des étiquettes relatives. Le préfixe local du client est la plage distante de la passerelle, et la plage locale de la passerelle est celle du client distant. Les captures d'écran des deux extrémités ne concordent donc jamais, et les comparer littéralement est la façon habituelle de perdre un après-midi.

Un répondeur peut resserrer une offre jusqu'à un sous-ensemble acceptable au lieu de la rejeter. Ce résultat est pire qu'un échec net, car il fonctionne à moitié. Demandez 10.0.0.0/16 alors que la politique autorise 10.0.5.0/24 et vous pouvez vous retrouver avec une SA enfant qui ne couvre que ce /24. Un hôte répond, tout le reste tombe dehors, et rien dans le client ne le dit. Lisez les sélecteurs acceptés plutôt que ceux demandés avant de conclure que la négociation a réussi.

Les profils road warrior qui demandent une route par défaut atterrissent ici en permanence. Une passerelle conçue pour un accès divisé resserre une offre de plage complète sur ses propres sous-réseaux, et le client doit accepter le résultat resserré ou échouer bruyamment.

Lisez le rejet à partir d'une seule tentative

Recueillez les deux journaux de la même tentative de connexion. Un profil enregistré montre ce que vous avez configuré, pas ce qui a été proposé, et sur strongSwan swanctl --log imprime la notification reçue avec les sélecteurs qu'elle portait.

Inspectez ensuite ce qui a réellement été installé. swanctl --list-sas montre les sélecteurs de la SA enfant, et ip xfrm policy montre les mêmes plages comme entrées de politique du noyau. Une SA enfant dans cette liste avec des sélecteurs que vous ne vouliez pas est un événement de resserrement ; aucune SA enfant plus TS_UNACCEPTABLE dans le journal est un refus.

Pendant que vous y êtes, séparez les voisins proches. INVALID_SELECTORS se plaint d'un sélecteur à l'intérieur d'une SA enfant établie, tandis qu'INTERNAL_ADDRESS_FAILURE signifie que le répondeur n'a pas pu allouer d'adresse virtuelle, ce qui est un problème de pool et non de couverture.

Vérifiez ce qui rétrécit l'ensemble en silence

Trois choses rétrécissent un ensemble de sélecteurs sans rien dire. La politique du répondeur est la première, via des listes de sous-réseaux, des règles de groupe ou une autorisation par utilisateur qui réduisent l'offre à un sous-ensemble. La famille d'adresses est la seconde : un client double pile propose souvent IPv6 à côté d'IPv4 et se voit refuser des plages que la passerelle n'a jamais configurées.

Les restrictions de protocole et de port sont la troisième. Là où la politique n'autorise que TCP 445, une SA enfant peut monter alors qu'ICMP et UDP restent en dehors, et l'utilisateur signale un tunnel cassé alors qu'un seul protocole était tout ce qui était autorisé.

Élargir les adresses seules ne peut donc pas corriger une politique restreinte par port, et c'est précisément le cas qui survivra le plus probablement à trois rondes de dépannage sans changement.

Prouvez la couverture avec du trafic qui convient

Une fois la SA enfant installée, envoyez une requête qui tombe à coup sûr dans les plages acceptées. Regardez les compteurs plutôt que l'icône d'état : ip -s xfrm state et les compteurs derrière ip xfrm policy augmentent lorsqu'un paquet est mis en correspondance et protégé. Un nombre d'octets qui reste à zéro après du trafic réel signifie que le noyau n'a jamais sélectionné cette politique.

Ce zéro est un problème de routage ou d'ordre des politiques, pas de cryptographie. Il ressemble aussi exactement à un rejet de sélecteur vu de la place de l'utilisateur, et c'est pourquoi les compteurs valent la peine d'être collectés avant de rouvrir le profil. Les compteurs qui ne montent que dans un sens pointent plutôt vers le chemin de retour.

Terminez en inscrivant la paire acceptée dans le ticket, à côté de la plage demandée à l'origine. Gardez la sélection aussi étroite que l'exige le besoin, car effacer l'erreur en remplaçant une plage privée par toutes les adresses accorde bien plus d'accès que ce qui a été approuvé pour le compte.