Distinguer la fragmentation IKEv2 d’un problème de chaîne de certificats

Le tunnel fonctionnait sur le réseau du bureau et se bloque à la maison, et le journal montre le premier échange se terminer avant que quoi que ce soit d’autre ne se produise. Ce schéma indique l’échange d’authentification, pas les identifiants : une chaîne de certificats rend ce message bien plus gros que le précédent, et un chemin qui n’aime pas les gros datagrammes le supprimera discrètement. Deux mécanismes de fragmentation différents sont en jeu, et savoir lequel on regarde décide de la correction.

Deux mécanismes de fragmentation, un symptôme

IKEv2 dispose de sa propre extension de fragmentation, définie dans RFC 7383, qui découpe les messages IKE protégés en messages IKE plus petits. Les pairs négocient cette capacité, et un message est réassemblé par l’implémentation IKE plutôt que par la couche IP.

La fragmentation IP ordinaire est un mécanisme différent avec un mode de défaillance différent. Un routeur entre les pairs fragmente un gros datagramme, ou le supprime et renvoie un message ICMP qui n’atteindra peut-être jamais l’émetteur. Certains réseaux jettent les fragments en silence, et certains intermédiaires traitent le premier fragment mais pas le reste. Du point de vue de l’application, les trois cas se ressemblent.

La traversée de NAT ajoute une troisième variable, car ESP est alors encapsulé dans UDP et le paquet externe grossit tout en ressemblant à du trafic UDP ordinaire sur le port 4500. Un chemin qui laisse bien passer l’UDP peut encore échouer sur un datagramme qui ne tient plus.

Lire l’échange qui a échoué

Cherchez la transition plutôt que l’erreur. Un journal qui montre l’échange initial envoyé et répondu, suivi de rien, vous dit que le message suivant ne s’est jamais terminé. Augmentez temporairement le niveau de journalisation et comparez les tailles rapportées des deux côtés.

Ce que vous voulez établir, c’est si le répondeur a vu la requête. Si l’initiateur a envoyé quelque chose et que le répondeur n’en a aucune trace, le problème est la livraison. Si le répondeur a analysé une requête et l’a rejetée, le certificat lui-même est le problème, et la fragmentation est une distraction. Cette distinction vaut plus qu’une page de messages d’expiration.

Changez le chemin, pas le certificat

Testez le même client, le même certificat et la même configuration depuis un autre réseau. Un point d’accès mobile est généralement le second chemin le moins cher, et il est réellement différent de la liaison du bureau, pas seulement nominalement.

Si la poignée de main aboutit sur le second chemin, la chaîne de certificats est bonne et le premier chemin est la variable. Si elle échoue de façon identique sur les deux, cessez de tester des réseaux et regardez les messages eux-mêmes. Cette seule comparaison élimine environ la moitié des explications possibles.

Mesurez l’échange avant de modifier quoi que ce soit

Obtenez la taille de la chaîne et la taille du chemin. Les deux chiffres limitent ce que la poignée de main peut envoyer, et les deux se mesurent à peu de frais :

openssl crl2pkcs7 -nocrl -certfile chain.pem | openssl pkcs7 -print_certs -noout | grep -c subject
ls -l chain.pem
ping -M do -s 1400 198.51.100.7
ip -s link show eth0 | sed -n '1,6p'

Les deux premiers donnent le nombre de certificats et la taille du fichier, ce qui est un indicateur raisonnable de la taille du message d’authentification. La sonde ping indique si un datagramme de cette taille survit au chemin, et les compteurs d’interface montrent si des fragments ont été abandonnés de votre côté. Sous Windows, la sonde équivalente est un ping avec l’indicateur do-not-fragment et une taille de charge utile explicite.

Répétez la sonde vers le bas jusqu’à ce qu’elle réussisse. La plus grande taille qui passe est le budget de travail pour ce chemin, et elle est plus utile que toute valeur par défaut publiée.

Réparez la couche qui est réellement cassée

Si le chemin abandonne les gros datagrammes, activez la fragmentation IKE des deux côtés et confirmez que l’extension a été négociée et pas seulement proposée. Si le chemin gère mal les fragments au niveau IP, la correction appartient à cet endroit ou au MTU de l’interface extérieure, pas au magasin de certificats.

Si la chaîne est inutilement longue, réduisez-la aux certificats intermédiaires dont un pair a réellement besoin. Retirer une racine à laquelle le client fait déjà confiance est un entretien raisonnable ; retirer un intermédiaire ne l’est pas, et désactiver la vérification pour réduire un message échange un problème de livraison contre un problème de sécurité.

Notez quel mécanisme vous avez modifié et à quoi ressemblait la poignée de main ensuite. L’occurrence suivante se produit généralement sur un autre réseau avec le même symptôme, et la note est ce qui transforme deux heures en dix minutes.