Linux EHOSTUNREACH avec OpenVPN : quel saut suivant a échoué ?

EHOSTUNREACH est une décision locale aussi souvent qu’une défaillance distante. Le noyau peut rejeter un paquet parce qu’une route dit que la destination est inaccessible, parce que le saut suivant Ethernet n’a jamais répondu, ou parce qu’un rapport ICMP host-unreachable est arrivé de plus loin sur le chemin. Chaque source vit dans une table ou un cache différent, et chacune se corrige à un endroit différent. Lisez la route sélectionnée et l’état du saut suivant avant de toucher aux chiffrements ou de réinstaller le tunnel.

Choisissez l’adresse et l’espace de noms que le client utilise réellement

Commencez par figer la destination et l’espace de noms réseau qui a produit l’erreur. Un client VPN peut tourner dans son propre espace de noms, et une recherche depuis l’espace de noms par défaut consulte une autre table de routage avec d’autres règles de politique.

La recherche doit utiliser le même contexte de source, de marque et de table que l’application qui échoue, sinon elle peut répondre à une question que personne n’a posée. Pour un pair IPv4 illustratif, les contrôles en lecture seule sont :

ip -4 route get 198.51.100.25
ip -4 neigh show 198.51.100.1
ip -4 route show table all | grep -w unreachable

Un résultat obtenu dans un shell administratif ne prouve que ce que ce shell ferait. Si le client pose une marque de pare-feu ou se lie à un VRF, répétez la recherche avec la marque correspondante ou à l’intérieur du VRF, et comparez la route sélectionnée et le saut suivant. La première adresse à confirmer est celle du pair dans le profil, pas le cluster ou le service que l’utilisateur nomme.

Une route inaccessible explicite rejette le paquet localement

Une route de type unreachable est une réponse locale délibérée. Elle dit au noyau de jeter le paquet et de renvoyer EHOSTUNREACH à l’expéditeur, ce qui explique pourquoi l’erreur apparaît instantanément et sans qu’aucun trafic ne quitte la machine. Quelqu’un, ou une automatisation, a placé cette route là exprès.

Les types de route ne sont pas interchangeables. Blackhole jette le paquet sans erreur à l’expéditeur, prohibit renvoie EACCES et unreachable renvoie EHOSTUNREACH. Un assistant VPN qui installe une route puits pendant la reconnexion peut donc produire une rafale d’erreurs host-unreachable qui disparaissent une fois le tunnel monté, tandis qu’une route blackhole produirait plutôt des délais d’attente silencieux.

Cherchez le type dans toutes les tables avant de blâmer l’extrémité distante. La règle qui sélectionne la table compte autant que la route qu’elle contient, et une route ajoutée à la table principale n’aidera pas un client dont la règle de politique envoie son trafic ailleurs.

Un voisin mort produit la même erreur sur Ethernet

Lorsque la route sélectionnée utilise une passerelle sur le lien, la livraison a besoin d’une adresse de couche de liaison résolue. Le noyau envoie une sollicitation de voisin ARP ou IPv6, et si aucune réponse n’arrive, le paquet ne peut pas être tramé. L’envoi échoue alors avec EHOSTUNREACH alors même que la route elle-même est valide.

La table des voisins nomme l’étape. INCOMPLETE signifie qu’une résolution est encore en cours, FAILED signifie que la dernière tentative n’a pas obtenu de réponse, et REACHABLE ou STALE signifie que le noyau dispose d’une adresse utilisable. Une entrée FAILED pour la passerelle VPN est un problème de livraison local, pas une preuve concernant l’autre côté du tunnel.

Lisez l’entrée du saut suivant réel, pas celle de l’adresse internet distante. Une adresse distante est normalement atteinte via un routeur, elle n’aura donc pas son propre enregistrement ARP ; en demander un est une erreur de catégorie qui envoie les gens chercher une entrée absente qui n’aurait jamais dû exister.

Rapports distants et erreurs UDP asynchrones

EHOSTUNREACH peut aussi venir de l’extérieur. Un routeur qui ne peut pas transmettre le paquet peut envoyer ICMP host unreachable, et le noyau transmet ce rapport à la socket qui possède le flux. Dans ce cas, la route et le voisin sont corrects, et la défaillance appartient à un saut au-delà du réseau local.

UDP rend l’attribution plus difficile. Une erreur renvoyée par un appel d’envoi ou de réception ultérieur peut se rapporter à un datagramme antérieur, si bien que l’adresse et l’heure de l’appel qui échoue peuvent ne pas correspondre au paquet qui a déclenché le rapport. Une socket UDP connectée reçoit l’erreur une fois, et une socket non connectée peut ne jamais la voir.

C’est pourquoi le moment fait partie des preuves. Notez quand l’erreur est apparue, quelle adresse de pair la socket utilisait et si le tunnel venait d’être reconnecté. Une rafale juste après un changement de route pointe vers la table locale ; une erreur isolée quelques minutes après le début d’un flux stable pointe vers un rapport de chemin.

Séparez les couches avant de changer la cryptographie

Trois questions classent l’erreur. Le noyau a-t-il choisi une route qui rejette la destination ? A-t-il choisi une route valide mais échoué à résoudre le saut suivant ? Ou un rapport est-il arrivé de au-delà du réseau local ? Seul le troisième cas peut impliquer l’extrémité distante du tunnel, et même alors il n’implique pas le chiffrement.

Les problèmes d’authentification et de négociation se manifestent comme leurs propres erreurs une fois que le transport atteint le pair. Changer un chiffrement ou réinstaller le client ne peut pas corriger une route unreachable locale, et cela détruit les preuves de route et de voisin dont vous auriez besoin pour la cause réelle.

Enregistrez la destination, l’espace de noms, la table sélectionnée, le saut suivant, l’état du voisin et l’heure de l’erreur avant le premier changement. Relancez la même recherche après la correction ; une route qui pointe désormais vers le tunnel et une entrée de voisin qui se résout maintenant sont une preuve plus forte qu’un ping réussi vers une adresse sans rapport.