Le ping depuis la passerelle IPsec utilise une autre adresse source

Pingez le côté distant depuis la passerelle IPsec, n’obtenez aucune réponse et concluez que le tunnel est cassé, alors que chaque charge de travail derrière la passerelle fait passer du trafic normalement. Les deux résultats ne se contredisent pas. Un ping lancé sur la passerelle est un paquet à source locale, et la passerelle choisit une adresse source dans sa propre table de routage. Ce choix peut différer des adresses qu’utilise le trafic réel du site, ce qui change la politique qui correspond et le chemin de retour qui s’applique. Décidez ce que le test doit prouver avant d’en tirer la moindre conclusion.

Trois questions différentes auxquelles un ping peut répondre

La première question est de savoir si l’extrémité distante est joignable depuis cet hôte. La deuxième est de savoir si les sélecteurs du tunnel ou la politique fondée sur les routes admettent le trafic d’une source donnée. La troisième est de savoir si le trafic transféré depuis une charge de travail derrière la passerelle fonctionne de bout en bout. Une seule commande ne peut pas répondre aux trois, et c’est l’adresse source qui les sépare.

Choisissez d’abord la question. Sinon, un ping raté devient la preuve de la théorie que vous aviez déjà.

Pourquoi la passerelle choisit une adresse que vous n’attendiez pas

Lorsque vous pingez une destination, la pile locale choisit une source sur la route qui y correspond. Sur un tunnel fondé sur les routes, cela peut être l’adresse de lien de l’interface du tunnel, qui dans beaucoup de conceptions de site est une paire 169.254.x.x choisie pour le saut point à point. Ces adresses existent pour faire fonctionner le lien ; elles ne sont pas annoncées comme réseaux sources d’applications du côté distant.

L’extrémité distante peut donc recevoir une demande d’écho d’une adresse vers laquelle elle n’a pas de route de retour, ou d’une adresse qu’aucun sélecteur ne fait correspondre. Le tunnel peut être sain et le ping échouer quand même, et c’est exactement le faux négatif dont traite cet article.

Choisissez la source délibérément

Sur une passerelle Linux maîtrisée, choisissez une source déjà attribuée localement : ping -c 4 -I 10.30.0.1 10.40.0.20. Les adresses ici sont illustratives, remplacez-les donc par la véritable adresse intérieure de la passerelle et une véritable destination distante, et vérifiez que la source choisie appartient à cet appareil et qu’elle est admise par la politique du site.

N’empruntez pas l’adresse d’une charge de travail pour le test. Se faire passer pour un hôte qui n’est pas attribué à la passerelle crée un résultat que personne ne peut reproduire, et sur certaines piles cela échoue de manières qui ressemblent à une panne du tunnel.

Lisez le chemin de retour, pas seulement la requête

Vérifiez quelle source arrive réellement à la destination distante, y compris toute traduction délibérée en chemin. Vérifiez ensuite la route de retour du côté distant vers cette source et les sélecteurs ou la politique qui l’autorisent. Une requête qui arrive avec une source inattendue est une question de routage et de politique, pas de cryptographie.

C’est aussi là qu’une capture aide plus qu’un autre ping : elle montre la source que l’extrémité distante a vue, et c’est l’adresse que sa réponse doit atteindre.

Testez ensuite la charge de travail

Le test décisif est un ping d’un hôte ordinaire derrière la passerelle vers un hôte ordinaire derrière la passerelle distante. Cela exerce le rôle de transfert de la passerelle, la vraie source applicative et le véritable chemin de retour, qui est le flux dont les utilisateurs se soucient.

Gardez les résultats séparés dans vos notes : joignabilité depuis la passerelle, admission par la politique pour une source choisie et trafic transféré. Un ping épinglé réussi est une preuve utile que le tunnel transporte quelque chose ; ce n’est pas la preuve que chaque flux transféré fonctionne. Et une source de passerelle choisie automatiquement qui n’est pas joignable n’est pas la preuve que le tunnel du site est tombé.

N’ajoutez pas une route générale pour 169.254.0.0/16 juste pour obtenir une réponse de diagnostic. Cela échange un test trompeur contre une décision de routage permanente, et la personne suivante en hérite sans le contexte.