L'entrée server-map est correcte. La route est correcte. L'entrée ARP est correcte. Et le mappage ne fonctionne toujours pas — car c'est précisément le fait que toutes ces vérifications passent qui permet à cette panne de se cacher de l'ordre de dépannage évident. Voici la chaîne de diagnostic qui va un cran plus loin, jusqu'au compteur du plan de transfert qui nomme réellement le problème.
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
server-map normal, route normale, ARP normal — et le client sur internet ne peut toujours pas atteindre le serveur mappé.
Un mappage NAT Server qui ne fonctionne tout simplement pas est l'une des pannes les plus déroutantes sur un routeur Huawei AR, précisément parce que les trois premières choses que tout le monde vérifie — display firewall server-map nat-server, display ip routing-table, display arp — reviennent toutes propres. Si vous avez déjà configuré NAT Server correctement (voir notre guide de configuration Easy IP pour la mise en place elle-même), la panne n'est pas dans la définition du mappage ; elle se situe quelque part dans le chemin de transfert en dessous, et le moyen le plus rapide d'y arriver est une vérification de la table de sessions suivie d'un compteur de rejet de paquets du plan de transfert, pas un nouveau regard sur la configuration NAT.
Voici cette chaîne de diagnostic dans l'ordre, les causes racines qu'elle révèle réellement, et des réponses de FAQ tirées de cas de terrain sur les comportements de NAT Server qui continuent de prêter à confusion.
Quatre vérifications semblent parfaitement normales dans cette panne, une par une, avant que le rejet réel n'apparaisse sur un compteur du plan de transfert que personne ne pense à vérifier en premier.
C'est une chaîne linéaire, pas une bifurcation — chaque étape confirme soit « pas ici » et vous envoie à la vérification suivante, soit nomme la cause réelle et vous évite de revérifier une configuration qui n'a jamais été le problème.
Les légendes du schéma restent en anglais pour la clarté technique.
Les deux premières étapes valent la peine d'être confirmées rapidement puis d'être faites confiance — retourner revérifier le server-map ou la route une deuxième et une troisième fois après qu'elles soient déjà revenues propres est le plus grand gouffre à temps de cette panne. La table de sessions et le compteur de transfert sont ce qui distingue réellement « le mappage est faux » de « le mappage est correct mais le transfert ne l'utilise jamais ».
Les deux premières vérifications confirment que le mappage n'est pas le problème — les deux dernières prouvent le rejet et le nomment.
Trois commandes, toutes propres, et aucune d'elles n'est là où se trouve réellement la panne.
<sysname> display firewall server-map nat-server
Current Total Server-map : 2
Type: Nat Server, ANY -> 100.1.1.101[192.168.205.101], Zone:---, protocol:---
Vpn: public -> public
Type: Nat Server Reverse, 192.168.205.101[100.1.1.101] -> ANY, Zone:---, protocol:---
Vpn: public -> public, counter: 1
// both forward and reverse entries present -- mapping itself is fine
[sysname] display ip routing-table 192.168.205.101
Destination/Mask Proto Pre Cost Flags NextHop Interface
192.168.205.0/24 Direct 0 0 D 192.168.205.1 10GE0/0/1
// route resolves correctly
[sysname] display arp network 192.168.205.101 32
IP ADDRESS MAC ADDRESS EXP(M) TYPE/VLAN INTERFACE VPN-INSTANCE
192.168.205.101 0000-c0a8-cd65 11 D 10GE0/0/1
// real MAC, not Incomplete -- ARP is fine tooC'est là que la panne se révèle réellement — un cran en dessous de tout ce que vous avez déjà confirmé comme correct.
<sysname> system-view
[sysname] diagnose
[sysname-diagnose] display forward information cpu-forward slot 0 cpuid 0 "hsd diag set pfa counter debug 0 1"
[sysname-diagnose] display forward information cpu-forward slot 0 cpuid 0 "hsd diag clear pfa counter 1"
// trigger the Telnet attempt against the mapped port here, then read the counter
[sysname-diagnose] display forward information cpu-forward slot 0 cpuid 0 "hsd diag show pfa counter all 1"
Module | error | Value
[ 4]IPV4
[ 4]ERROR_CNT_IPV4_ARPMISS 14
[ 6]ERROR_CNT_IPV4_NHP_DWN 14
[ 62]ERROR_CNT_BLACK_HOLE 37
// ARP Miss and black-hole counts climbing -- traffic never resolved to the right next hop
[sysname] interface 10GE0/0/1
[sysname-10GE0/0/1] display this
#
interface 10GE0/0/1
ip address 100.1.1.100 255.255.255.0
device transceiver 10GBASE-FIBER
#
// nat enable is missing here -- ingress traffic never went through server-map translation
[sysname-10GE0/0/1] nat enableUne fois que la chaîne ci-dessus vous a indiqué que le mappage et la route n'ont jamais été le problème, ces cinq causes couvrent l'essentiel du problème réel.
SYMPTÔMELe server-map, la route et l'ARP pour l'adresse interne sont tous propres, mais aucune session n'est jamais créée pour le trafic visant l'adresse publique mappée, et le compteur d'erreurs ARP-Miss du plan de transfert grimpe à chaque essai.
CAUSEL'entrée server-map existe globalement sur l'appareil, mais la traduction NAT ne s'exécute réellement que sur une interface où nat enable est configuré. Sans cela, le trafic destiné à l'adresse publique mappée est transféré comme une simple recherche IP contre cette adresse — qui n'était jamais censée être routée nulle part — au lieu d'être d'abord traduit vers l'adresse interne.
SOLUTIONConfirmez avec display this sur l'interface entrante, puis ajoutez nat enable.
[sysname-10GE0/0/1] display this
#
interface 10GE0/0/1
ip address 100.1.1.100 255.255.255.0
#
[sysname-10GE0/0/1] nat enableSYMPTÔMELe trafic dans une direction sur le même chemin fonctionne bien ; l'autre direction échoue, même si la configuration des deux extrémités et la liaison elle-même sont vérifiées — display ike sa (ou l'équivalent du tunnel) montre tout établi.
CAUSELe comportement automatique de session inverse de NAT Server prime sur une politique de source-NAT, même une qui refuse explicitement de traduire le trafic protégé. L'adresse privée est traduite en adresse publique de toute façon sur le chemin de retour, cassant ce qui attendait que ce trafic arrive non traduit.
SOLUTIONConfigurez no-reverse sur la commande nat server lorsque l'adresse côté serveur ne devrait jamais être traduite qu'en entrée, jamais sur son propre trafic sortant ; vérifiez display firewall server-map pour l'entrée « Nat Server Reverse » afin de confirmer qu'elle est réellement en jeu.
[sysname2] nat server 0 protocol tcp global 2.1.1.10 3389 inside 10.1.2.2 3389 no-reverseSYMPTÔMEAucun symptôme évident tant que vous n'approfondissez pas — mais sous charge, ou après un changement de topologie, le trafic vers l'adresse globale du NAT Server commence à boucler entre l'appareil et le routeur en aval au lieu d'atteindre le serveur.
CAUSELorsque l'adresse du pool NAT ou l'adresse globale du NAT Server n'est pas sur le même sous-réseau que l'interface de sortie, l'appareil a quand même besoin qu'une route pour elle existe localement afin qu'un appareil en aval n'essaie pas de renvoyer le trafic correspondant. Sans route en trou noir, l'appareil en aval croit que la destination est encore accessible via l'appareil et la renvoie, formant une boucle.
SOLUTIONConfigurez une route en trou noir pour l'adresse globale du NAT Server (ou la plage du pool NAT) chaque fois qu'elle n'est pas sur le même sous-réseau que l'interface de sortie physique — et envisagez-en une même quand c'est le cas, car cela empêche aussi l'appareil de générer des requêtes ARP inutiles pour une adresse qui n'est en réalité jamais un vrai hôte.
[sysname] ip route-static 100.1.1.101 255.255.255.255 NULL0SYMPTÔMELe mappage et la route semblent tous deux corrects, mais le trafic est toujours rejeté, et le rejet ne se dissipe qu'une fois la politique de sécurité/ACL réécrite pour référencer l'adresse privée du serveur plutôt que la publique.
CAUSELa traduction NAT Server se produit avant la vérification de la politique de sécurité dans l'ordre de transfert — dès qu'un paquet correspond à l'entrée server-map, son adresse de destination est déjà réécrite vers l'adresse interne au moment où l'évaluation de la politique a lieu. Une politique écrite contre la destination publique d'origine ne correspondra jamais.
SOLUTIONÉcrivez l'adresse de destination de la politique de sécurité comme l'adresse privée (interne) du serveur, pas l'adresse publique configurée dans le mappage NAT Server.
SYMPTÔMEVous voulez confirmer que le trafic touche réellement une entrée NAT Server ou pool spécifique, par opposition à simplement exister en tant que mappage, et les commandes évidentes n'affichent pas de compteur par entrée.
CAUSEIl n'existe aucune commande display qui indique directement combien de paquets ont correspondu à une entrée spécifique de NAT Server ou de pool d'adresses NAT.
SOLUTIONUtilisez plutôt display nat-policy rule all — elle indique un compteur HITS par règle de politique NAT, ce qui est le meilleur indicateur disponible pour confirmer qu'une règle donnée (et par extension son server-map ou pool associé) est réellement mise en correspondance par du trafic réel.
<sysname> display nat-policy rule all
Total:3
RULE ID RULE NAME STATE ACTION HITS
1 test disable no-nat 0
2 abc enable src-nat 5
0 default enable no-nat 0Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.
Techniquement oui, mais évitez-le. Une fois que cette IP d'interface devient l'adresse globale du NAT Server, chaque paquet destiné à l'interface elle-même est d'abord traduit vers l'adresse interne du serveur — ce qui casse le ping, la gestion Web et Telnet vers l'appareil sur cette adresse. Utiliser l'IP de l'interface pour la traduction source-NAT à la place n'a pas ce problème, car le trafic activement initié vers l'interface suit le processus du premier paquet et contourne la politique de source-NAT.
Pas directement. Il n'existe aucun compteur dédié à une seule entrée NAT Server ou pool NAT. display nat-policy rule all est ce qui s'en rapproche le plus — elle indique un compteur HITS par règle de politique NAT configurée.
Deux cas : lorsque le pool NAT ou l'adresse globale du NAT Server est sur un sous-réseau différent de l'interface de sortie (obligatoire, pour éviter une boucle de transfert), et — cela vaut la peine de le faire de toute façon — même lorsqu'elle est sur le même sous-réseau, car cela empêche l'appareil de générer des requêtes ARP inutiles pour une adresse qui n'a jamais été un vrai hôte.
C'est le comportement no-reverse. Sans lui, la session inverse automatique du NAT Server traduit le propre trafic sortant du serveur vers la même adresse publique que le mappage — ce qui est généralement correct. Mais si une politique de source-NAT ou un pool d'adresses différent gère aussi le trafic sortant de ce serveur, les deux traductions divergent et les connexions échouent ; alignez-les sur la même adresse publique, ou appliquez no-reverse et configurez explicitement le NAT sortant pour cet hôte.
Parce que la traduction NAT Server se produit avant la vérification de la politique de sécurité. Au moment où la politique évalue le paquet, la destination est déjà devenue l'adresse interne privée. Pointez plutôt l'adresse de destination de la politique vers l'adresse interne.
Le guide de configuration vous amène à un mappage correctement défini. Cette note concerne le cas où la définition est déjà correcte et que le trafic n'arrive toujours pas — ce qui signifie presque toujours que la panne se trouve un cran plus bas, dans le fait que la traduction NAT soit réellement appliquée à l'interface entrante, ou dans un rejet du plan de transfert que le mappage lui-même ne peut pas vous montrer.
Cette note s'appuie sur le modèle de panne NAT Server du routeur Huawei série AR, les diagnostics server-map / forward information cpu-forward et les cas de terrain qui les sous-tendent. Sur d'autres plateformes, les compteurs de rejet du plan de transfert équivalents se trouvent sous des commandes différentes, mais la chaîne sous-jacente — mappage, route, ARP, session, rejet de transfert, activation NAT sur l'interface — s'applique directement. Elle ne couvre pas en profondeur les déploiements NAT Server équilibrés en charge ou multi-actifs, ni les scénarios NAT64/NAT-PT.
Envoyez-nous votre sortie de display firewall server-map nat-server ainsi que l'étape de cette chaîne que vous avez confirmée propre, et nous vous aiderons à lire le reste.