Pourquoi traceroute meurt dans un seul sens à travers un tunnel VPN

La sortie de traceroute qui se termine dans un sens et imprime des lignes d’astérisques dans l’autre ressemble à un transfert asymétrique, et ce n’est généralement pas le cas. Chaque saut affiché exige que la sonde arrive, qu’un routeur décide de répondre et que la réponse revienne et soit associée à la sonde. Cassez l’un de ces maillons et la ligne devient un astérisque, tandis que le tunnel continue de transporter des données.

La trace est une preuve sur le diagnostic avant d’être une preuve sur le transport. La question qui vaut la peine d’être posée est lequel des trois maillons a échoué, et la réponse vient des paquets, non de la forme de la sortie.

Un astérisque est une réponse manquante, pas un saut manquant

Traceroute progresse vers l’extérieur en envoyant des sondes dont le TTL expire un routeur plus loin à chaque tour. Un routeur qui rejette une sonde expirée est censé renvoyer un message ICMP Time Exceeded qui le nomme, et l’outil imprime ce nom. Ce que l’outil attend réellement, c’est que ce message arrive dans un délai. Si le routeur répond depuis une autre adresse source, limite la fréquence à laquelle il génère des erreurs ou abandonne la sonde sans un mot, le tour ne produit rien d’imprimable.

Aucun de ces résultats ne dit que le chemin aller est cassé. Un astérisque est un rapport sur du courrier sans réponse, pas sur une route vide.

La méthode de sonde décide quel filtre vous rencontrez

La méthode par défaut sous Linux est généralement un port de destination UDP à numéro élevé, tracert sous Windows envoie des échos ICMP, et l’on peut demander à Linux d’utiliser ICMP ou TCP à la place. Chacune ressemble à un type de trafic différent pour un pare-feu à états ou un groupe de sécurité cloud. Comparer une trace UDP d’un côté avec une trace ICMP de l’autre compare deux expériences différentes. Fixez la méthode, la famille d’adresses, l’adresse source et le délai avant de qualifier les résultats de différence.

Pour une comparaison honnête, lancez la trace depuis les hôtes qui transportent réellement le trafic plutôt que depuis une passerelle qui relaie à leur place. Une trace générée par le routeur utilise sa propre adresse source et sa politique de sortie, qui peuvent être plus strictes que tout ce qu’un client voit. Notez l’invocation exacte pour que la personne suivante puisse la répéter.

La valeur du délai est l’autre moitié de l’expérience, et il est facile de l’omettre des notes. Une attente de deux secondes sur un chemin congestionné rapporte des astérisques là où une attente de cinq secondes rapporte des sauts. Gardez la valeur identique d’une exécution à l’autre pour que la comparaison reste au sujet du réseau.

Le chemin de retour est une route à part entière

Une erreur ICMP est un paquet ordinaire avec sa propre source et sa destination, et il a besoin d’une route de retour vers le traceur. Si la politique du tunnel transporte les préfixes du LAN mais pas l’adresse du routeur qui a généré l’erreur, le message part par un chemin qui ne peut pas vous atteindre. Le filtrage des réponses peut le supprimer même lorsque la route existe, car le paquet arrive d’une adresse inattendue sur une interface inattendue. C’est un désaccord dans le plan de diagnostic et non une défaillance de l’application.

Élargir chaque sélecteur jusqu’à ce que la trace se termine rend l’image plus jolie et la politique pire. Réparez l’adresse de diagnostic précise, ou acceptez l’astérisque et testez l’application autrement.

Confirmez le tunnel avec une vraie requête

Une poignée de main TCP sur le port propre au service exerce le transfert, le routage de retour et le filtrage dans le sens qui compte. Les commandes ci-dessous s’exécutent aux deux extrémités et comparent ce que chaque côté peut ouvrir. Remplacez le port du service et le nom de l’interface du tunnel par ceux de votre propre configuration.

traceroute -I -n -w 2 203.0.113.40
traceroute -T -p 443 -n -w 2 203.0.113.40
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' --max-time 5 http://203.0.113.40:8080/health
ss -tan state established

Lisez d’abord les deux exécutions de traceroute : si l’exécution ICMP montre des sauts et que l’exécution TCP non, la différence est la méthode, pas le chemin. Prenez ensuite le résultat de curl comme réponse au niveau applicatif, car un échange terminé avec un code d’état raisonnable signifie que les chemins aller et retour fonctionnent pour le trafic réel. La liste des sockets montre si la connexion est établie, ce qu’aucune trace ne peut vous dire.

Un tunnel qui transporte une session interactive dans les deux sens tandis qu’une trace imprime des astérisques est sain et simplement peu photogénique. Conservez la sortie des commandes de chaque côté comme enregistrement, et traitez les sauts manquants comme une question ouverte sur le diagnostic plutôt qu’un verdict sur le VPN.