Le ping ne fonctionne que dans un sens : pourquoi Windows abandonne l’écho du serveur

Votre client fait un ping vers le serveur, le serveur ne peut pas pinguer le client, et le tunnel transporte manifestement des paquets dans ces deux affirmations. Ce qui diffère n’est pas le chemin mais le premier paquet de chaque test : l’un est une réponse à un flux que Windows suit déjà, l’autre une nouvelle requête entrante qu’aucune règle n’a admise. Cette différence explique la plupart des rapports de ping unidirectionnel et désigne directement la règle que vous devez écrire. Deux tests menés dans des sens opposés séparent les cas en une minute environ.

Deux sens, deux décisions différentes

Quand le client envoie la requête d’écho, le pare-feu Windows voit une connexion sortante qu’il a décidé d’autoriser. La réponse revient à l’intérieur de ce flux établi, si bien que le moteur à états l’admet sans consulter la moindre règle entrante pour ICMP. C’est ce que signifie le filtrage à états en pratique, et la règle que personne n’a écrite n’entre pas en jeu. La réussite du client ne dit donc rien de la politique entrante.

Quand le serveur envoie la requête le premier, aucun état ne lui correspond. Windows traite le paquet comme une nouvelle connexion entrante et interroge la politique entrante, qui par défaut ne prévoit rien pour les requêtes d’écho venues de sources arbitraires.

La réussite du client a donc prouvé que l’ICMP sortant et le chemin de retour fonctionnent. Elle n’a jamais éprouvé la décision entrante, et la conclusion naturelle, que le pare-feu est correct, est raisonnable et fausse. Voilà pourquoi l’erreur se répète dans des tickets qui contiennent déjà la preuve.

Suivez le paquet jusqu’à sa disparition

Confirmez les adresses avant de changer quoi que ce soit : utilisez l’adresse de tunnel que le client détient réellement et vérifiez que le serveur route vers elle et non vers une adresse LAN derrière le client. Les deux échecs se ressemblent à l’invite du serveur, car tous deux se terminent par un délai dépassé. L’endroit où le paquet meurt est le seul fait qui décide de ce qu’il faut changer.

Si la requête atteint l’interface du tunnel et que rien n’en sort, le pare-feu local est la raison probable. Si elle n’atteint jamais l’interface, la réponse est en amont : une route sur le serveur, une politique sortante ou la livraison propre au VPN entre pairs.

Capturez sur l’interface du tunnel du client pendant que le serveur fait un ping. Voir la requête arriver sans réponse à côté est la preuve qui justifie d’écrire une règle Windows. Ne rien voir du tout vous renvoie en amont, et une règle ajoutée dans cet état ne fait que rendre la machine plus permissive pour un paquet jamais arrivé. Dans les deux cas, la capture coûte moins que les suppositions qu’elle remplace.

Limitez une règle au lieu d’ouvrir ICMP

Identifiez l’adaptateur et sa catégorie actuelle avant d’écrire quoi que ce soit, car les deux figurent dans la portée que vous allez fixer. Cet alias est le nom de l’interface Windows, qui n’est pas nécessairement le nom du profil VPN que vous avez importé. Les commandes ci-dessous listent ce qui existe, puis prévisualisent une règle limitée sans l’appliquer.

Get-NetConnectionProfile
Get-NetAdapter | Where-Object Status -eq 'Up'
New-NetFirewallRule -DisplayName "VPN server echo" -Direction Inbound -Protocol ICMPv4 -IcmpType 8 -RemoteAddress 10.63.0.1 -InterfaceAlias "Office VPN" -Profile Private -Action Allow -WhatIf

ICMPv4 type 8 est la requête d’écho, le seul message auquel le serveur doit répondre. Limitez-la à l’adresse de tunnel du serveur et à l’interface du tunnel, et laissez le profil tel que l’adaptateur est réellement. Renommer un réseau pour le faire cadrer avec un exemple est un changement distinct, avec ses propres conséquences.

Ce que la règle ne couvre pas

L’écho IPv6 est un autre protocole avec un autre type de message, donc une règle ICMPv4 n’en dit rien, et un tunnel qui transporte les deux familles a besoin de sa propre règle pour l’autre. Cette règle n’ouvre rien d’autre non plus : RDP, le partage de fichiers et tous les autres services dépendent toujours de leur propre politique. C’est tout l’intérêt de limiter une règle étroite au lieu d’activer une large autorisation ICMP. La large autorisation est la solution facile et celle qui survit le plus longtemps, parce que personne ne la remarque ensuite.

Sur un appareil géré, la règle peut être remplacée au prochain rafraîchissement de politique, aussi le propriétaire de la politique doit-il faire le changement équivalent, et non un administrateur local. Écrivez l’intention dans le ticket en plus de la commande, car un rafraîchissement effacera la commande et laissera l’exigence intacte. Les deux ne sont pas le même artefact, et un seul survit.

Lisez le résultat dans le bon sens

Une fois la règle appliquée, faites un ping depuis le serveur et confirmez qu’une réponse atteint le client, puis faites un ping depuis une source qui doit encore rester exclue et confirmez qu’elle n’atteint pas. Répétez le test d’accessibilité sur l’autre famille d’adresses si le tunnel en transporte une.

Get-NetFirewallRule -DisplayName "VPN server echo" | Get-NetFirewallAddressFilter
ping 10.63.4.17
ping -6 fd00:63::17

Afficher la règle entrée en vigueur est plus utile que de faire confiance à la commande qui l’a créée, car un aperçu et une règle appliquée sont deux états différents. Si le filtre d’adresses montre la source voulue et que la source exclue expire encore, la règle fait exactement ce que dit sa portée. Un ping réussi parti du client n’aurait jamais démontré cela, et c’est pourquoi le sens de chaque test appartient au compte rendu, à côté de son résultat. Gardez les deux sens dans le ticket, sinon le prochain lecteur répétera le test qui ne peut pas échouer.