Accueil / Notes techniques / Dépannage : le tunnel VPN ne répond pas au Ping

Le tunnel VPN est actif mais le Ping échoue : diagnostiquer les décalages d'encapsulation GRE et de routage

Un tunnel GRE qui monte mais qui ne laisse toujours pas les deux sites se pinger mutuellement sur leur adresse de tunnel est l'un des tickets VPN les plus courants en phase initiale. Voici l'ordre qui trouve la panne le plus vite — l'encapsulation avant le routage, les commandes display exactes pour chaque étape, les vérifications qui ne comptent qu'une fois l'interface déjà active, et les vrais cas de mauvaise configuration derrière tout cela.

Par Yuwen Zhang (Atlas), fondateur d'AtlasCommTech — 13 ans de déploiements de réseaux opérateurs et d'entreprise · Mis à jour en juillet 2026

Pourquoi l'encapsulation passe avant le routage

Le réflexe est de se mettre immédiatement à pinguer et à tracer les routes — mais sur un tunnel GRE, une bonne partie des échecs de Ping n'en arrivent même pas là : les deux côtés ne parlent pas encore la même encapsulation.

Une interface active ne signifie pas que le tunnel est sain, et une configuration qui semble correcte des deux côtés ne signifie pas que les deux sites peuvent réellement joindre l'adresse IP de l'interface Tunnel de l'autre. L'ordre qui trouve la panne le plus vite est : confirmer que les deux côtés utilisent la même encapsulation, confirmer que l'adressage du tunnel se reflète et est complet, confirmer qu'une route existe entre les deux adresses physiques source/destination, et seulement une fois l'interface elle-même réellement active, vérifier la clé GRE et la route vers l'adresse d'interface Tunnel du pair en particulier.

Voici l'ordre de diagnostic sur lequel ce texte s'appuie, tiré du propre modèle de classification des pannes GRE du routeur Huawei AR, les vérifications et commandes display pour chaque étape, un cas de mauvaise configuration documenté, et une série de réponses de FAQ tirées de la même documentation de maintenance. Si le tunnel sous-jacent est protégé par IPSec, « Le tunnel VPN IPSec ne monte pas ? » couvre la couche de négociation ; s'il s'agit d'une conception dynamique en étoile plutôt que d'un tunnel point à point fixe, « DSVPN over IPSec entre des succursales Huawei et un hub Cisco » couvre directement cette variante.

Lisez l'arbre de panne avant de toucher à la configuration

Les échecs de Ping GRE se répartissent en trois formes : l'interface Tunnel elle-même ne monte jamais, elle est active mais les deux côtés ne peuvent toujours pas se pinger sur leur Tunnel IP, ou elle est active et le Ping fonctionne mais la liaison est instable ou lente.

Placer d'abord le symptôme sur cet arbre indique quelle étape ci-dessous s'applique réellement — et, plus utilement, si l'on est même face à un problème de routage.

Les légendes du schéma restent en anglais pour la clarté technique.

Presque chaque vérification de la branche de gauche est un simple décalage de configuration qui doit correspondre, champ par champ, des deux côtés. La branche du milieu est ce qui reste une fois que l'interface elle-même est saine mais que les deux adresses Tunnel IP ne se joignent toujours pas ; la branche de droite est un problème de conception du routage, pas une erreur de configuration du tunnel.

Parcourir chaque étape

Quatre points de contrôle, chacun avec sa propre commande display — l'arbre de panne ci-dessus indique par lequel commencer.

Étape 0 — Confirmer que les deux côtés utilisent la même encapsulation

Si le protocole de couche réseau de l'interface Tunnel ne monte pas du tout, ne touchez pas encore au routage — l'encapsulation est la première chose qui doit correspondre.

Vérifiez la configuration propre de l'interface avec display this dans la vue de l'interface Tunnel. La sortie affiche directement tunnel-protocol gre — c'est l'encapsulation réellement utilisée, pas seulement ce que vous pensez avoir configuré.
Si les deux côtés affichent des valeurs tunnel-protocol différentes, reconfigurez celui qui est erroné. Reconfigurer tunnel-protocol sur un routeur Huawei efface la source et la destination précédemment configurées, il faut donc les ressaisir immédiatement après.
Si l'encapsulation correspond déjà, vérifiez ensuite l'adressage : les deux côtés ont besoin d'une adresse IP plus une source et une destination configurées, et — c'est la partie facile à manquer — les deux côtés doivent se refléter exactement, la destination de ce côté étant la source du pair et inversement. Le couple source/destination identifie de manière unique un tunnel ; si les deux côtés ne se reflètent pas, aucun tunnel unique ne se forme jamais.

[Huawei-Tunnel0/0/0] display this
[V200R009C00SPC300]
#
interface Tunnel0/0/0
 ip address 172.16.1.1 255.255.255.252
 tunnel-protocol gre
 source GigabitEthernet1/0/0
 destination 1.1.1.2
#
return
// tunnel-protocol gre confirms the actual encapsulation in use
// source/destination on this end must mirror the peer's destination/source

Étape 1 — Route entre la source et la destination physiques du tunnel

Une encapsulation et un adressage corrects ne suffisent pas à faire monter l'interface si les deux extrémités physiques ne peuvent pas réellement se joindre.

Si les interfaces source et destination ne sont pas directement connectées, il doit exister une route entre elles — vérifiez avec display ip routing-table, puis confirmez que la table de transfert concorde avec display fib.
Si aucune route n'existe entre les adresses source et destination, ajoutez une route statique, ou annoncez le réseau de destination via le protocole de routage dynamique déjà en cours entre les deux interfaces physiques.
Ce n'est qu'une fois la joignabilité source-destination confirmée qu'il est pertinent de continuer à dépanner le tunnel lui-même plutôt que le réseau de transport sous-jacent.

<Huawei> display ip routing-table
<Huawei> display fib
// confirm the FIB table agrees with the routing table before assuming
// the tunnel itself is the problem rather than the transport network below it

Étape 2 — L'interface est active, mais les deux côtés ne peuvent toujours pas se pinger sur leur Tunnel IP

C'est là que se cache une deuxième paire de vérifications moins évidente : la clé GRE, et une route vers l'adresse d'interface Tunnel du pair en particulier — pas seulement son adresse physique.

Vérifiez si une clé GRE (mot-clé d'identification) est configurée d'un côté ou de l'autre avec gre key. Si elle est définie, les deux côtés doivent porter la même valeur ; si vous préférez ne pas la gérer, assurez-vous qu'aucun des deux côtés ne la configure.
Confirmez que chaque côté a réellement une route vers l'adresse IP de l'interface Tunnel du pair, pas seulement vers son adresse physique source/destination — un tunnel actif peut très bien n'avoir aucun chemin vers l'adresse logique de l'autre extrémité. GRE prend en charge le routage statique, OSPF, IS-IS, RIP et BGP sur le tunnel précisément pour cette raison.
Ce n'est qu'après que la clé correspond et qu'une route vers le Tunnel IP du pair existe qu'un Ping vers cette adresse a une réelle chance de réussir.

Étape 3 — Le Ping réussit, mais le tunnel oscille ou ralentit

Deux symptômes d'apparence très différente remontent à la même cause profonde : la route vers l'adresse de destination du tunnel lui-même pointe vers le mauvais type d'interface sortante.

Si l'interface Tunnel elle-même oscille Up/Down, vérifiez avec display ip routing-table l'interface sortante de l'adresse de destination. Si cette interface sortante est l'interface Tunnel GRE elle-même, la route est récursive — replanifiez le réseau pour que la destination ne soit jamais atteinte en repassant par le tunnel qui en dépend.
Si le tunnel reste actif mais que le débit est faible, vérifiez la même entrée de table de routage pour voir si l'interface sortante est une interface VLANIF — cette combinaison est une cause documentée de faible débit GRE et nécessite une replanification, pas un réglage.
Lorsque la bande passante n'est pas en cause mais que certaines sessions sont lentes ou intermittentes, testez avec ping -s packetsize -a source-ip-address host en augmentant la taille pour trouver le point de rupture où la perte commence, ajustez le MTU de l'interface en conséquence, et utilisez tcp adjust-mss value si les sessions TCP en particulier sont encore affectées après le changement de MTU.

<Huawei> ping -s packetsize -a source-ip-address host
// increase packetsize until loss appears -- that breakpoint sets the working MTU

[Huawei-Tunnel0/0/0] mtu mtu-value
[Huawei-Tunnel0/0/0] tcp adjust-mss value

6 causes qui reviennent sans cesse

Une fois que les étapes ci-dessus ont indiqué où se situe le problème, ces six causes expliquent l'essentiel de ce qui ne va vraiment pas.

1. Le mode d'encapsulation ne correspond pas réellement

SYMPTÔMELe protocole de couche réseau de l'interface Tunnel ne monte jamais, quoi que le reste de la configuration de l'interface ait l'air correct.

CAUSEtunnel-protocol doit être identique des deux côtés ; display this de chaque côté est le seul moyen fiable de voir ce qui est réellement configuré, car un type d'encapsulation discordant est autrement totalement silencieux — aucun journal, aucun message d'erreur.

SOLUTIONReconfigurez tunnel-protocol gre du côté qui est erroné ; comme cela efface la source et la destination existantes, ressaisissez-les immédiatement après.

[Huawei-Tunnel0/0/0] tunnel-protocol gre
[Huawei-Tunnel0/0/0] source GigabitEthernet1/0/0
[Huawei-Tunnel0/0/0] destination 1.1.1.2

2. La source et la destination ne se reflètent pas réellement

SYMPTÔMELes deux côtés semblent entièrement configurés, individuellement, mais l'interface Tunnel ne monte jamais.

CAUSELe couple source/destination identifie un seul tunnel ; si la destination de ce côté n'est pas la source du pair (et inversement), les deux côtés construisent techniquement chacun un tunnel différent qui ne se rencontre jamais.

SOLUTIONLisez display this des deux côtés côte à côte et confirmez explicitement le miroir — ne faites pas simplement confiance à celui qui a configuré l'autre extrémité.

3. La clé GRE n'est configurée que d'un seul côté

SYMPTÔMEL'interface Tunnel est active des deux côtés, l'encapsulation et l'adressage sont tous deux corrects, mais les deux côtés ne peuvent toujours pas se pinger sur leur Tunnel IP.

CAUSEgre key est facultatif, mais si l'un ou l'autre côté le configure, les deux doivent porter la même valeur — une clé définie d'un côté et laissée non définie (ou définie différemment) de l'autre empêche le tunnel de faire réellement passer le trafic, même si l'état de l'interface semble parfaitement sain.

SOLUTIONConfigurez soit la même valeur gre key des deux côtés, soit retirez-la des deux — ne la laissez jamais configurée d'un seul côté.

4. Aucune route vers l'IP de l'interface Tunnel du pair

SYMPTÔMELes adresses physiques source et destination sont joignables et l'interface est active, mais un Ping vers le Tunnel IP du pair échoue toujours.

CAUSEUn tunnel actif confirme seulement que l'underlay physique est joignable — atteindre l'adresse logique de l'interface Tunnel du pair est une question de routage distincte, résolue via le protocole de routage qui tourne sur le tunnel, pas quelque chose que l'état actif du tunnel implique automatiquement.

SOLUTIONConfirmez qu'une route vers le Tunnel IP du pair existe — via un protocole de routage tournant sur le tunnel (GRE prend en charge le routage statique, OSPF, IS-IS, RIP et BGP), ou une route statique — avant de supposer que le tunnel lui-même est cassé.

5. La route de destination boucle à travers le tunnel lui-même

SYMPTÔMELe Ping fonctionne bien, mais l'interface Tunnel oscille Up/Down de façon répétée, ou le débit est étonnamment faible, sans rien d'autre visiblement anormal.

CAUSESi la route vers l'adresse de destination du tunnel lui-même se résout avec l'interface Tunnel GRE elle-même comme interface sortante, le tunnel dépend de lui-même pour rester actif — une cause documentée d'oscillation. Par ailleurs, une route de destination dont l'interface sortante est une interface VLANIF est une cause documentée de faible débit.

SOLUTIONVérifiez avec display ip routing-table l'interface sortante de l'adresse de destination en particulier ; si c'est le tunnel lui-même, replanifiez le routage sous-jacent pour que la destination soit atteinte via une interface physique réelle, pas le tunnel qui en dépend.

6. La table de sessions NAT prime sur la table de routage après une oscillation du tunnel

SYMPTÔMEDans un déploiement GRE over IPSec, le trafic empruntait le tunnel, le tunnel est passé à Down et le trafic a basculé vers le NAT, et quand le tunnel est redevenu actif, le trafic est resté sur le NAT au lieu d'y revenir.

CAUSEC'est un cas réel documenté. Une fois que le trafic a basculé vers une session NAT, cette entrée de la table de sessions NAT a une priorité plus élevée que la table de routage — donc même après que le tunnel GRE soit de nouveau actif et que la table de routage pointerait correctement le trafic vers lui, la session NAT existante continue de l'emporter.

SOLUTIONVidez la table de sessions NAT pour que le trafic se résolve à nouveau selon la table de routage désormais correcte et revienne au tunnel ; ne présumez pas que « tunnel actif » à lui seul signifie que le trafic y est réellement retourné.

<RouterA> system-view
[RouterA] reset nat session all
Warning:The current all NAT sessions will be deleted.
Are you sure to continue?[Y/N]Y

Six questions qui reviennent constamment

Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.

Qu'est-ce qui fait vraiment échouer la montée d'un tunnel GRE en premier lieu ?

Par ordre de fréquence : décalage d'encapsulation entre les deux côtés ; adresse IP, source ou destination non configurée, ou non reflétée entre les deux côtés ; clé GRE configurée de façon incohérente ; absence de route entre les adresses physiques source et destination ; une configuration Keepalive où les compteurs d'envoi/réception ne concordent pas ; des valeurs de MTU discordantes entre les deux côtés ; et une valeur TCP MSS d'interface réglée assez haut pour que la trame plus les frais généraux dépassent le MTU.

L'interface Tunnel s'affiche active des deux côtés — que reste-t-il à vérifier si les deux côtés ne peuvent toujours pas se pinger sur leur Tunnel IP ?

Deux choses en particulier : un décalage de clé GRE (configurée d'un côté et pas de l'autre, ou configurée avec des valeurs différentes), et une route manquante vers l'adresse d'interface Tunnel du pair elle-même — la joignabilité entre les adresses physiques source et destination ne donne pas automatiquement une route vers le Tunnel IP logique par-dessus.

Le tunnel fonctionnait bien et a soudainement commencé à osciller ou ralentir — qu'est-ce qui a changé ?

Rien n'a nécessairement changé dans la configuration propre du tunnel. Vérifiez si l'interface sortante de la route de destination est le tunnel lui-même — c'est une cause documentée d'oscillation par routage récursif — ou une interface VLANIF, une cause documentée de faible débit. Les deux sont des problèmes de conception réseau à replanifier, pas des erreurs de configuration du tunnel à corriger.

GRE prend-il en charge les protocoles de routage dynamique et le multicast sur le tunnel ?

Oui — GRE prend en charge le routage statique, OSPF, IS-IS, RIP et BGP sur le tunnel, et peut transporter des protocoles multicast dont PIM. C'est l'une des raisons pour lesquelles GRE over IPSec existe : un tunnel IPSec pur ne protège que le trafic unicast, donc tout multicast nécessitant un chiffrement est d'abord encapsulé en GRE, puis IPSec protège ensuite le tunnel GRE lui-même.

Si j'ai déjà un tunnel IPSec entre deux sites, pourquoi ajouter du GRE par-dessus ?

Deux raisons ordinaires : un tunnel IPSec seul ne protège que le trafic unicast, donc tout multicast nécessitant aussi un chiffrement — appel vocal, certains protocoles de routage — doit d'abord être encapsulé en GRE puis remis à IPSec ; et GRE vous donne une véritable interface logique sur laquelle faire tourner un protocole de routage dynamique, ce qu'une simple politique IPSec ne fournit pas par elle-même. Voir « DSVPN over IPSec entre des succursales Huawei et un hub Cisco » pour un exemple concret exactement de cette combinaison.

Définir un MTU sur l'interface Tunnel a-t-il un effet réel ?

Oui — un MTU configuré sur l'interface Tunnel GRE s'applique au trafic transféré via ce tunnel ; tout ce qui dépasse la valeur configurée est fragmenté avant l'envoi. C'est exactement le mécanisme sur lequel repose le test ping -s de l'étape 3 ci-dessus.

Limites honnêtes de cette note

Limites honnêtes de cette note

Cette note s'appuie sur le modèle de classification des pannes GRE du routeur Huawei série AR — display this, display ip routing-table, display fib — et sur les cas de terrain qui les sous-tendent, tirés de la même documentation de maintenance. Elle suppose un tunnel GRE statique point à point, pas la variante mGRE dynamique de DSVPN ni un déploiement GRE over IPSec entièrement développé. Pour la négociation IPSec superposée à un tunnel comme celui-ci, voir « Le tunnel VPN IPSec ne monte pas ? » ; pour le cas multipoint dynamique, voir « DSVPN over IPSec entre des succursales Huawei et un hub Cisco ».

Bloqué sur un tunnel actif qui ne répond pas au Ping ?

Dites-nous si l'interface Tunnel elle-même est active, avec la sortie de display this des deux côtés, et nous vous aiderons à l'interpréter.

WhatsApp avec un ingénieur →