Canal de contrôle et canal de données VPN : vérifier la bonne couche

Le client dit connecté, le serveur voit un pair, et l’application n’atteint toujours rien. À ce stade, la question utile n’est pas quel chiffrement changer, mais quel canal a échoué. OpenVPN nomme explicitement deux fonctions : un canal de contrôle qui négocie et gère la session, et un canal de données qui transporte le trafic protégé. IKEv2 exprime une séparation comparable par l’association IKE et l’association CHILD. Faites les vérifications ci-dessous dans l’ordre, car un correctif du chemin de données appliqué à une panne du chemin de contrôle gaspille une fenêtre de changement.

Nommez le canal avant de le déboguer

Le côté contrôle négocie le matériel de sécurité, authentifie les pairs et gère la connexion. Le côté données transporte le trafic choisi dès que l’état nécessaire existe.

Ils échouent différemment. Une panne de contrôle vous laisse en général sans aucune session utilisable, ou avec une session qui renégocie en boucle. Une panne de données laisse une session qui semble saine alors que les paquets sont abandonnés, mal routés ou protégés par des paramètres que l’autre côté n’acceptera pas. La ligne de journal que vous lisez vous dit dans quel cas vous êtes, alors lisez l’étiquette avant le texte de l’erreur.

Vérifiez l’échange de contrôle

Confirmez que la poignée de main se termine et que les deux côtés s’accordent sur le transport, la version de TLS et la méthode d’authentification. Les journaux d’OpenVPN impriment des lignes distinctes pour le canal de contrôle et le canal de données, et c’est sur la ligne de contrôle qu’apparaît une divergence de certificat, de version de TLS ou de tls-crypt.

Si l’échange de contrôle échoue, examinez le port joignable, la chaîne de certificats et ses dates de validité, l’horloge système, le recouvrement des chiffrements entre client et serveur, et toute clé tls-auth ou tls-crypt. Une grande chaîne de certificats peut aussi échouer sur la MTU du chemin avant qu’une authentification ne se termine, ce qui ressemble à un délai d’attente et non à une erreur cryptographique.

Corrigez les pannes de contrôle avec des réglages de contrôle. Augmenter le chiffrement des données ou assouplir la politique d’authentification des données n’achèvera pas une poignée de main qui n’a jamais dépassé l’échange de certificats.

Vérifiez le canal de données séparément

Une fois la session établie, confirmez le chiffrement et le mode de données négociés, la dérivation des clés et le comportement de renouvellement de clé. Sous OpenVPN, la ligne du canal de données indique le chiffrement et la taille de clé réellement initialisés, qui peuvent différer du premier chiffrement du profil.

Vérifiez ensuite ce que la session a installé. Un PUSH_REPLY peut ajouter des routes, un serveur DNS et une directive redirect-gateway, et chacun d’eux peut envoyer du trafic là où l’application ne peut pas l’utiliser. Pour IKEv2, la question équivalente est de savoir si les sélecteurs de l’association CHILD correspondent aux adresses du flux réel.

tls-auth et tls-crypt appartiennent au canal de contrôle. Ils authentifient ou chiffrent la poignée de main et ne choisissent pas le chiffrement des données de l’application. Si vous en ajoutez un en espérant un changement du chemin de données, la seule chose que vous avez changée est la poignée de main.

Reliez les noms à IKEv2 et OpenVPN

IKEv2 possède une association de sécurité IKE et une ou plusieurs associations CHILD. L’association IKE transporte les échanges de contrôle ; l’association CHILD transporte le trafic protégé et ses sélecteurs. Elles sont négociées et renouvelées selon des calendriers distincts, si bien que l’une peut être saine alors que l’autre ne l’est pas.

ESP n’a pas en lui de canal de contrôle de style TLS. Le protocole de contrôle est IKE, et ESP est la charge protégée. Appeler ESP le canal de données est un raccourci commode qui devient trompeur quand on lit une capture de paquets, car la capture montre les messages IKE et les paquets ESP comme des protocoles différents sur le fil.

Gardez la correspondance explicite dans vos notes : le canal de contrôle OpenVPN et l’IKE SA sont le côté gestion, le canal de données OpenVPN et le CHILD SA sont le côté trafic, et les implémentations ne sont pas interchangeables même quand la séparation semble similaire.

Cessez de changer le mauvais réglage

Parcourez le chemin dans un seul sens : échange de contrôle, protection des données, acheminement, puis résolution de noms. Arrêtez-vous à la première étape qui échoue et ne corrigez que celle-là. Une session connectée avec un ping qui fonctionne vers la passerelle mais sans trafic applicatif est un problème d’acheminement ou de sélecteurs, pas de poignée de main.

Écrivez les preuves de chaque étape séparément dans le ticket : la ligne de journal du contrôle, les paramètres de données négociés, les routes installées et une vraie requête. Cette structure empêche qu’une vérification d’identité qui fonctionne soit affaiblie pour réparer un problème de routage ultérieur qu’elle n’a jamais causé, et elle empêche qu’un changement de chiffrement des données soit vendu comme correctif d’une erreur de certificat.

La documentation du protocole OpenVPN fait référence pour la séparation entre contrôle et données ; utilisez-la quand l’interface d’un fournisseur emploie d’autres mots pour les mêmes deux fonctions.