Ping n’est pas une preuve : testez le chemin entre deux sites

Le tunnel est monté, les passerelles se répondent, et les utilisateurs d’un site ne peuvent toujours pas ouvrir le partage de fichiers de l’autre. Quelqu’un fait un ping depuis la passerelle, obtient une réponse et déclare le réseau sain. Cette réponse a voyagé entre deux appareils qui n’ont jamais été le problème. Un test utile part de l’hôte qui a besoin du service, utilise le protocole que l’application utilise et reproduit la condition dans laquelle il échoue. Tout le reste est un feu vert pour un chemin que personne n’emprunte.

Partez du client qui a besoin du service

Notez quatre choses avant de tester quoi que ce soit : l’adresse du client, l’adresse de destination, le nom d’hôte et le port de l’application. Confirmez ensuite que le service fonctionne localement sur son propre site, depuis un hôte voisin. Sans cette base, vous ne pouvez pas distinguer un tunnel cassé d’un service cassé, et la moitié de ces tickets sont le second cas.

Essayez le nom d’hôte documenté et, là où le service le permet, une vérification d’adresse directe du même port. Une résolution de nom échouée et une adresse résolue injoignable vous mènent par des chemins différents. Si vous remplacez un nom d’hôte par une IP, ne désactivez pas la vérification d’identité HTTPS pour que cela fonctionne ; un avertissement de certificat est une information, pas un obstacle.

Parcourez le chemin à chaque extrémité

Lisez la route que le client choisit, puis la route que la passerelle choisit pour cette destination, puis les compteurs ou une capture limitée à chaque extrémité. Vous cherchez deux faits : la requête est-elle arrivée sur le LAN distant, et une réponse est-elle revenue. Les compteurs d’interface incluent tous les autres flux, alors corrélez par horodatage exact et paire d’adresses plutôt que par la forme du graphique. Une capture prise à la mauvaise extrémité est pire qu’aucune, parce qu’elle ressemble à une preuve.

ip route get 10.10.0.5
sudo tcpdump -ni any host 10.10.0.5 and port 445
sudo tcpdump -ni any net 10.10.0.0/24 and net 10.20.0.0/24

Si la requête apparaît à l’extrémité distante sans réponse derrière, le problème est de l’autre côté : un pare-feu, une route de retour manquante ou un hôte qui n’accepte pas la source. Si la requête n’apparaît jamais, la route locale ou les sélecteurs du tunnel ne l’ont pas transportée, et l’autre côté ne mérite pas encore l’enquête.

Utilisez le protocole que l’application utilise

ICMP est une sonde faible. Il peut être filtré, limité en débit ou traité par une politique différente de celle du service, ce qui rend ambigus son succès comme son échec. Testez le port réel et, quand vous le pouvez, la poignée de main réelle du protocole.

nc -vz 10.10.0.5 445
curl -sv --max-time 5 https://files.corp.internal/ -o /dev/null
openssl s_client -connect 10.10.0.5:443 -servername files.corp.internal

Une poignée de main TCP terminée prouve l’accessibilité et la politique pour ce port. Elle ne prouve pas que l’application fonctionne : l’authentification, un téléversement ou un appel API précis peuvent encore échouer. Testez l’opération que les utilisateurs effectuent réellement, avec un équivalent inoffensif plutôt qu’en soumettant à répétition une transaction réelle.

Reproduisez la condition qui échoue

Les échecs qui n’apparaissent qu’avec de gros transferts sont un problème de taille, pas de connectivité. Envoyez un gros paquet avec le bit don't-fragment activé et regardez où il s’arrête. Si une petite requête réussit et qu’une grosse se bloque, le MTU du tunnel et le traitement MSS sur les passerelles sont les suspects suivants.

ping -M do -s 1400 10.10.0.5
ping -M do -s 1472 10.10.0.5
curl -sS --max-time 30 -F file=@./sample.bin https://files.corp.internal/upload

Si un seul sous-réseau échoue, regardez les sélecteurs de trafic, les annonces de routes et la passerelle de retour de ce sous-réseau. Si seul le nom d’hôte échoue, suivez le DNS, notamment quel résolveur le client a utilisé et si la vue distante est visible depuis ce site. Trois pannes différentes, trois corrections différentes, et le test de ping n’en distingue aucune.

Après la correction, répétez le même test

Relancez le même client, la même destination, le même port et la même charge. Puis reconnectez-vous ou exercez le chemin de basculement si la conception en prévoit un, car une correction qui ne fonctionne que tant que l’instance d’origine du tunnel est vivante n’a pas été testée. Gardez le test lié à une source réelle, une destination réelle et une opération réelle plutôt qu’à un voyant vert sur un tableau de bord.

Notez les quatre valeurs de base et le résultat. Le prochain signalement du même symptôme pourra alors partir de preuves plutôt que d’un ping.