A entrada de server-map está correta. A rota está correta. A entrada ARP está correta. E o mapeamento ainda não funciona — porque exatamente todas essas verificações passarem é o que faz essa falha se esconder da ordem óbvia de solução de problemas. Esta é a cadeia de diagnóstico que vai um nível mais fundo, até o contador do plano de encaminhamento que realmente nomeia o problema.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
server-map normal, rota normal, ARP normal — e o cliente na internet ainda não consegue alcançar o servidor mapeado.
Um mapeamento de NAT Server que simplesmente não funciona é uma das falhas mais desorientadoras em um roteador Huawei AR, precisamente porque as três primeiras coisas que qualquer um verifica — display firewall server-map nat-server, display ip routing-table, display arp — voltam todas limpas. Se você já configurou o NAT Server corretamente (veja nosso guia de configuração do Easy IP para a configuração em si), a falha não está na definição do mapeamento; está em algum lugar do caminho de encaminhamento abaixo dela, e a forma mais rápida de chegar lá é uma verificação da tabela de sessões seguida de um contador de descarte de pacotes do plano de encaminhamento, não outra olhada na configuração de NAT.
A seguir está essa cadeia de diagnóstico em ordem, as causas raiz que ela realmente revela, e respostas de perguntas frequentes de casos de campo sobre os comportamentos do NAT Server que continuam causando confusão.
Quatro verificações parecem completamente normais nesta falha, uma de cada vez, antes que o descarte real apareça em um contador do plano de encaminhamento que ninguém pensa em verificar primeiro.
Esta é uma cadeia linear, não uma bifurcação — cada etapa confirma "não está aqui" e o envia para a próxima verificação, ou nomeia a causa real e evita que você reverifique uma configuração que nunca foi o problema.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
As duas primeiras etapas valem a pena ser confirmadas rapidamente e depois confiadas — voltar a verificar o server-map ou a rota pela segunda e terceira vez depois que já voltaram limpas é o maior desperdício de tempo nesta falha. A tabela de sessões e o contador de encaminhamento são o que realmente distingue "o mapeamento está errado" de "o mapeamento está certo mas o encaminhamento nunca chega a usá-lo".
As duas primeiras verificações confirmam que o mapeamento não é o problema — as duas últimas provam o descarte e o nomeiam.
Três comandos, todos limpos, e nenhum deles é onde a falha realmente está.
<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 tooÉ aqui que a falha realmente se mostra — um nível abaixo de tudo o que você já confirmou estar bem.
<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 enableDepois que a cadeia acima indicar que o mapeamento e a rota nunca foram o problema, essas cinco explicam a maior parte do que realmente está errado.
SINTOMAO server-map, a rota e o ARP para o endereço interno estão todos limpos, mas nenhuma sessão é criada para o tráfego direcionado ao endereço público mapeado, e o contador de erro de ARP-Miss do plano de encaminhamento sobe a cada tentativa.
CAUSAA entrada de server-map existe globalmente no dispositivo, mas a tradução de NAT só é realmente executada em uma interface onde o nat enable está configurado. Sem isso, o tráfego destinado ao endereço público mapeado é encaminhado como uma simples busca de IP contra esse endereço — que nunca deveria ser roteado para lugar nenhum — em vez de ser traduzido para o endereço interno primeiro.
SOLUÇÃOConfirme com display this na interface de entrada, depois adicione 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 enableSINTOMAO tráfego em uma direção pelo mesmo caminho funciona bem; a outra direção falha, mesmo que a configuração de ambas as pontas e o próprio link estejam corretos — display ike sa (ou o equivalente do túnel) mostra tudo estabelecido.
CAUSAO comportamento automático de sessão reversa do NAT Server tem prioridade sobre uma política de source-NAT, mesmo uma que nega explicitamente traduzir o tráfego protegido. O endereço privado é traduzido para o endereço público de qualquer forma no caminho de retorno, quebrando o que esperava que esse tráfego chegasse sem tradução.
SOLUÇÃOConfigure no-reverse no comando nat server quando o endereço do lado do servidor só deve ser traduzido na entrada, nunca em seu próprio tráfego de saída; verifique display firewall server-map para a entrada "Nat Server Reverse" para confirmar que ela está realmente em jogo.
[sysname2] nat server 0 protocol tcp global 2.1.1.10 3389 inside 10.1.2.2 3389 no-reverseSINTOMANenhum sintoma óbvio até você investigar — mas sob carga, ou após uma mudança de topologia, o tráfego em direção ao endereço global do NAT Server começa a formar um loop entre o dispositivo e o roteador a jusante em vez de chegar ao servidor.
CAUSAQuando o endereço do pool de NAT ou o endereço global do NAT Server não está na mesma sub-rede que a interface de saída, o dispositivo ainda precisa que exista uma rota local para ele, para que um dispositivo a jusante não tente devolver o tráfego correspondente. Sem uma rota de buraco negro, o dispositivo a jusante acredita que o destino ainda é alcançável através do dispositivo e o envia de volta, formando um loop.
SOLUÇÃOConfigure uma rota de buraco negro para o endereço global do NAT Server (ou a faixa do pool de NAT) sempre que ele não estiver na mesma sub-rede que a interface de saída física — e considere uma mesmo quando estiver, já que isso também impede o dispositivo de gerar solicitações de ARP desnecessárias para um endereço que nunca é realmente um host real.
[sysname] ip route-static 100.1.1.101 255.255.255.255 NULL0SINTOMAO mapeamento e a rota parecem corretos, mas o tráfego ainda é descartado, e o descarte só se resolve depois que a política de segurança/ACL é reescrita para referenciar o endereço privado do servidor em vez do público.
CAUSAA tradução do NAT Server acontece antes da verificação da política de segurança na ordem de encaminhamento — assim que um pacote corresponde à entrada de server-map, seu endereço de destino já foi reescrito para o endereço interno no momento em que a avaliação da política ocorre. Uma política escrita contra o destino público original nunca corresponderá.
SOLUÇÃOEscreva o endereço de destino da política de segurança como o endereço privado (interno) do servidor, não o endereço público configurado no mapeamento do NAT Server.
SINTOMAVocê quer confirmar que o tráfego está realmente atingindo uma entrada específica de NAT Server ou pool, em vez de apenas existir como mapeamento, e os comandos óbvios não mostram um contador por entrada.
CAUSANão existe nenhum comando display que reporte diretamente quantos pacotes corresponderam a uma entrada específica de NAT Server ou pool de endereços NAT.
SOLUÇÃOUse display nat-policy rule all em vez disso — ele reporta um contador HITS por regra de política de NAT, que é o proxy disponível mais próximo para confirmar que uma determinada regra (e, por extensão, seu server-map ou pool associado) está realmente sendo correspondida por tráfego real.
<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 0Tiradas diretamente do campo — as que vale a pena ter uma resposta pronta.
Tecnicamente sim, mas evite. Depois que esse IP de interface se torna o endereço global do NAT Server, todo pacote destinado à própria interface é traduzido primeiro para o endereço interno do servidor — o que quebra o ping, o gerenciamento Web e o Telnet para o dispositivo nesse endereço. Usar o IP da interface para tradução de source-NAT em vez disso não tem esse problema, já que o tráfego iniciado ativamente em direção à interface segue o processo do primeiro pacote e contorna a política de source-NAT.
Não diretamente. Não há um contador dedicado a uma única entrada de NAT Server ou pool de NAT. display nat-policy rule all é o mais próximo disso — ele reporta uma contagem de HITS por regra de política de NAT configurada.
Dois casos: quando o pool de NAT ou o endereço global do NAT Server está em uma sub-rede diferente da interface de saída (obrigatório, para evitar um loop de encaminhamento), e — vale a pena fazer de qualquer forma — mesmo quando está na mesma sub-rede, já que impede o dispositivo de gerar solicitações de ARP inúteis para um endereço que nunca foi um host real.
Este é o comportamento no-reverse. Sem ele, a sessão reversa automática do NAT Server traduz o próprio tráfego de saída do servidor para o mesmo endereço público do mapeamento — o que geralmente está bem. Mas se uma política de source-NAT ou um pool de endereços diferente também estiver lidando com o tráfego de saída desse servidor, as duas traduções discordam e as conexões falham; alinhe-as ao mesmo endereço público, ou aplique no-reverse e configure o NAT de saída explicitamente para esse host.
Porque a tradução do NAT Server acontece antes da verificação da política de segurança. Quando a política avalia o pacote, o destino já se tornou o endereço privado interno. Aponte o endereço de destino da política para o endereço interno em vez disso.
O guia de configuração leva você a um mapeamento definido corretamente. Esta nota é para o caso em que a definição já está correta e o tráfego ainda não chega — o que quase sempre significa que a falha está um nível abaixo, em saber se a tradução de NAT está realmente sendo aplicada à interface de entrada, ou em um descarte do plano de encaminhamento que o próprio mapeamento não pode mostrar a você.
Esta nota se baseia no modelo de falhas de NAT Server do roteador Huawei série AR, nos diagnósticos de server-map / forward information cpu-forward e nos casos de campo por trás deles. Em outras plataformas, os contadores de descarte do plano de encaminhamento equivalentes ficam sob comandos diferentes, mas a cadeia subjacente — mapeamento, rota, ARP, sessão, descarte de encaminhamento, habilitação de NAT na interface — se aplica diretamente. Não cobre em profundidade implantações de NAT Server com balanceamento de carga ou multiativas, nem cenários NAT64/NAT-PT.
Envie-nos sua saída de display firewall server-map nat-server mais qual etapa desta cadeia você já confirmou estar limpa, e ajudamos você a interpretar o resto.