Les réponses DPD prouvent que le pair IKE est vivant, pas que vos données circulent
Les réponses de vivacité, une notification de remplissage et des sélecteurs rétrécis décrivent trois choses différentes. Lisez-les séparément avant d'en accuser une d'un blocage.
Les journaux IPsec peuvent afficher des réponses de vivacité alors que l'application devant eux se bloque, et les deux faits peuvent être vrais en même temps. Une réponse DPD établit que le traitement IKE du pair a répondu à cet instant ; elle ne dit rien sur le fait que l'enfant SA transporte ou non le paquet qui vous intéresse. Traiter chaque avertissement proche d'une panne comme sa cause, c'est ainsi qu'un problème de sélecteur se retrouve diagnostiqué comme un bogue de protocole. Trois observations sont le plus souvent confondues, et elles répondent à trois questions différentes. Lisez-les par association et par objet avant de les lire par horodatage.
Ce que prouve chaque observation
Le tableau sépare ce que chaque observation établit de ce qu'elle ne fait qu'accompagner.
| Observation | What it establishes | What it leaves open |
|---|---|---|
| DPD replies arrive | The peer's IKE process answered | The child SA, forwarding path and application reply |
| TFC padding notification | The peer will not accept padding for that child SA | Whether ordinary ESP protection still works, which it does |
| Selectors reported as narrowed | The accepted traffic set is a subset of the offer | Whether the subset includes the flow the user needs |
Aucune des trois n'est une erreur en soi. Chacune ne devient intéressante qu'à côté du flux que vous déboguez, et une ligne qui ne peut pas être reliée à un flux précis est un contexte, pas une preuve.
La vivacité n'est pas la santé des données
DPD s'exécute comme un échange INFORMATIONAL, une conversation de plan de contrôle entre démons IKE. Une réponse prouve que le processus IKE du pair est joignable et disposé à répondre, et un délai dépassé prouve qu'il ne l'est pas. Aucun des deux résultats n'éprouve l'enfant SA, les sélecteurs, le chemin de transfert ni la réponse de l'application, donc un DPD sain à côté d'un transfert bloqué est une image cohérente, pas une contradiction.
C'est pourquoi les lignes de vivacité sont la partie la moins utile d'un ticket de plan de données, aussi rassurantes paraissent-elles en haut du journal.
La notification de remplissage est une déclaration sur le remplissage
Le remplissage TFC est la ligne la plus surinterprétée de ces journaux. Elle dit que le remplissage de confidentialité du flux de trafic ne sera pas accepté pour cet enfant SA, ce qui est une déclaration sur une fonction de remplissage facultative et non un rejet de la protection ESP. La trouver près d'une défaillance est généralement une coïncidence de verbosité, et activer ou désactiver le remplissage ne change rien à la couverture des sélecteurs.
La spécification IKEv2 définit à la fois la notification et la négociation des sélecteurs, et l'étiquette d'avertissement d'une implémentation ne remplace pas le sens du protocole dans l'un ou l'autre cas.
Le rétrécissement est plus discret et plus susceptible d'avoir de l'importance
Un répondeur peut accepter un sous-ensemble des sélecteurs proposés, et l'ensemble accepté peut être imprimé sur plusieurs entrées, l'une qualifiée par port et l'autre couvrant tous les ports. Ne lire que la première ligne qualifiée par port sous-estime ce qui a été accepté ; ne lire que la ligne large le surestime. Comparez la proposition imprimée à la politique installée, car la proposition est ce que les pairs ont dit et la politique est ce que le noyau fera correspondre. Quand elles divergent, le tunnel existe et le trafic non, ce qui est la plainte intermittente classique. Inversez la perspective locale et distante lorsque vous comparez des pairs, puisque le local de chaque côté est le distant de l'autre.
Les entrées spécifiques à l'hôte avec une restriction de port méritent une double lecture, car ce sont elles qui excluent ICMP ou un second port tout en laissant un ping vers la passerelle fonctionner.
Construisez un enregistrement pour le flux qui échoue
Notez la source, la destination, la famille d'adresses, le protocole et le port tels qu'ils apparaissent à la décision de protection, y compris toute traduction délibérée. Ce sont les valeurs qui doivent correspondre à un sélecteur, et ce sont aussi les valeurs que les gens retapent de mémoire lorsque le ticket arrive à une troisième paire de mains.
Identifiez ensuite l'enfant SA et ses compteurs directionnels : swanctl --list-sas donne le résumé de l'association sur un hôte strongSwan, et ip -s xfrm state donne les compteurs. Lisez-les après une requête autorisée récente plutôt que pendant que le système est inactif. Aucune augmentation en sortie ne pointe vers la sélection ou le chemin local ; de la sortie sans entrée correspondante pointe vers le pair, son transfert ou ses réponses.
Un échange applicatif abouti prime sur l'un ou l'autre compteur, c'est pourquoi le test doit se terminer à l'application plutôt qu'à l'indicateur du tunnel.
Choisissez la correction ensuite
Ce n'est qu'une fois cet enregistrement établi qu'il y a une correction à choisir : sélecteurs acceptés, route, filtrage, implémentation du pair, ou une limite que vous venez de démontrer. Réinitialiser le pair change plusieurs états à la fois et rétablit souvent le trafic sans expliquer lequel était faux, si bien que la panne revient. Gardez aussi les vidages d'état du noyau hors des tickets, car ils peuvent contenir des clés et le résumé étroit suffit à quiconque doit aider.
Quand l'enregistrement contredit votre première théorie, croyez l'enregistrement et réécrivez la théorie ; cette habitude vaut plus que n'importe quelle ligne de journal évoquée ici.