Ping à travers un VPN : pourquoi les règles de réponse d’écho ratent le chemin de retour

Envoyez un ping vers un hôte à travers un VPN et la requête part avec un type ICMP et revient avec un autre, ce qui suffit à dérouter toute règle écrite en termes de ports. Il n’y a aucun port de service de destination dans un échange d’écho à recopier dans la règle de retour, et un filtre qui attend la symétrie rejettera la réponse pendant que la requête passe sans encombre. La correction commence par lire le paquet tel qu’il est réellement, puis par décider quelle frontière du chemin prend la décision. Deux couches fonctionnent généralement pendant que la troisième écarte silencieusement la réponse. Les sections ci-dessous les séparent dans l’ordre où un paquet les rencontre.

Le paquet change de type, pas de port

Une requête d’écho est de type ICMP 8, code 0, et porte un identifiant et un numéro de séquence. La réponse est de type 0, code 0, avec le même identifiant et la même séquence, et les extrémités IP inversées. La RFC 792 définit ces champs, et l’identifiant est ce qui permet à un émetteur d’apparier les réponses à ses propres requêtes.

Ce qui manque est tout aussi important : il n’y a pas d’en-tête TCP ni UDP, donc aucun port à autoriser. Une règle qui nomme un port pour une réponse d’écho décrit un paquet qui n’existera jamais. C’est l’erreur la plus fréquente dans les tickets de ping VPN. La règle paraît précise, ne s’applique à rien et laisse la panne exactement où elle était.

Trois contextes décident du paquet

Si le ping vise un hôte du LAN distant, la requête doit être transférée par la passerelle. Si elle vise une adresse qui appartient à la passerelle elle-même, elle se termine dans le chemin d’entrée local. Si la passerelle est à l’origine du ping, le paquet démarre dans son propre chemin de sortie et ne traverse jamais la décision de transfert.

Ces trois contextes ont des chaînes de règles et des compteurs différents, et les traiter comme un seul est la raison pour laquelle « le pare-feu autorise ICMP » peut encore produire un ping en échec. Le tunnel extérieur est un quatrième contexte : autoriser l’écouteur VPN n’autorise pas automatiquement la requête interne décapsulée, et une autorisation interne ne dit rien sur l’état du tunnel extérieur.

Les filtres à état et sans état traitent la réponse différemment

Un pare-feu à état qui a vu la requête sortir peut associer la réponse à ce flux et l’admettre sans seconde règle. Un filtre sans état n’a pas une telle mémoire, le sens du retour a donc besoin de sa propre autorisation explicite, avec la source et la destination inversées.

Vérifiez quel modèle le produit implémente réellement avant d’écrire quoi que ce soit. Une règle pour la requête d’écho ne couvre pas nécessairement la réponse d’écho, et un produit qui suit les requêtes ICMP peut encore appliquer une autre politique aux réponses qui arrivent sur une autre interface.

Limitez ce que vous autorisez. Autoriser toutes les réponses d’écho de n’importe où n’est pas la même chose que terminer une association à état, et un numéro de type n’authentifie pas l’émetteur.

La traduction change aussi l’identifiant

Si la traduction de source est intentionnelle, le tuple à l’extrémité distante ne correspond pas à celui envoyé par le client. Un NAT peut traduire l’identifiant de requête ICMP en même temps que les adresses, donc insister pour que le même numéro apparaisse des deux côtés produit un faux écart.

Corrélez plutôt la correspondance que le traducteur signale. Un traducteur qui réécrit l’identifiant ne conservera pas le numéro que votre client a journalisé, alors traitez la correspondance comme l’identité plutôt que le numéro. Suivez ensuite une requête identifiable sur le chemin : confirmez qu’elle atteint la destination avec la source attendue, confirmez que la destination a émis une réponse, suivez la route de cette réponse en retour, et confirmez que le client l’a reçue plutôt que de simplement regarder un compteur de passerelle monter.

Ne fusionnez pas les erreurs ICMP dans la politique d’écho

Le message « fragmentation nécessaire » utilisé par la découverte de MTU du chemin n’est pas une réponse d’écho, et sa charge utile cite le paquet qui l’a déclenché. Une autorisation limitée à l’écho qui écarte silencieusement ces erreurs transforme un problème de taille en connexion bloquée, ce qui est l’inverse d’utile.

La même prudence vaut pour les familles d’adresses. ICMPv6 utilise des types de messages différents et porte des fonctions essentielles qu’IPv4 n’a pas, donc copier ces numéros dans une règle IPv6 est simplement faux.

Quand l’échange d’écho fonctionne, testez l’application réelle séparément. Un ping réussi prouve l’aller-retour d’un protocole, à une taille et vers une destination, et ce n’est pas une licence pour supposer que HTTPS, SMB ou tout autre flux est autorisé.