Mapeamento do NAT Server morto: o diagnóstico de ARP Miss
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 Atlas Yuwen Zhang, fundador da AtlasCommTech — 18 anos em ICT, 13 deles em redes de operadoras · Atualizado em julho de 2026
Quando todas as verificações de configuração passam e o mapeamento ainda não funciona
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.
Entenda a cadeia antes de verificar o mapeamento novamente
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".
Percorrendo a cadeia
As duas primeiras verificações confirmam que o mapeamento não é o problema — as duas últimas provam o descarte e o nomeiam.
Etapas 1 e 2 — Confirmar que o mapeamento e a rota não são o problema
Três comandos, todos limpos, e nenhum deles é onde a falha realmente está.
- Execute display firewall server-map nat-server e confirme que tanto a entrada direta (Nat Server) quanto a reversa (Nat Server Reverse) existem para o endereço e a porta mapeados.
- Execute display ip routing-table para o endereço interno do servidor e confirme que uma rota se resolve para a interface de saída correta.
- Execute display arp network para o endereço interno e confirme que existe uma entrada dinâmica com um MAC real — não Incomplete.
- Se as três voltarem limpas, pare de verificar a configuração de NAT em si e passe para a tabela de sessões — este é o ponto da falha em que reler as mesmas três saídas pela segunda vez deixa de ser útil.
<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 tooEtapas 3 e 4 — Provar o descarte e nomeá-lo
É aqui que a falha realmente se mostra — um nível abaixo de tudo o que você já confirmou estar bem.
- De fora da rede, gere tráfego real em direção ao endereço público e à porta mapeados (uma tentativa de Telnet contra a porta exata basta), depois verifique se uma sessão foi criada para ele. Nenhuma sessão alguma confirma que o tráfego está sendo descartado em algum lugar do caminho de encaminhamento, não roteado incorretamente em silêncio.
- Ative o contador de pacotes do plano de encaminhamento para tráfego encaminhado por CPU, limpe-o, gere o tráfego novamente, depois leia-o e observe especificamente ERROR_CNT_IPV4_ARPMISS e ERROR_CNT_BLACK_HOLE. Uma contagem de erro de ARP-Miss subindo aqui — mesmo que o display arp em si parecesse bem no endereço interno — é o sinal de que esse tráfego nunca foi resolvido para o próximo salto correto.
- Verifique diretamente a configuração da interface de entrada com display this. Se o nat enable estiver faltando na interface voltada para o tráfego do lado público, essa é a resposta: os pacotes destinados ao endereço mapeado nunca passaram pela tradução de server-map — foram encaminhados como uma simples busca de IP para o destino público original, que não tem rota, daí o ARP Miss e o descarte de buraco negro.
- Adicione nat enable sob a interface e teste novamente com o mesmo gatilho Telnet; o mapeamento começa a funcionar imediatamente assim que a tradução é realmente aplicada ao tráfego de entrada.
<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 enable5 causas raiz que aparecem repetidamente
Depois 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.
1. Falta nat enable na interface de entrada
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 enable2. A sessão reversa do NAT Server tem prioridade sobre uma regra de negação de source-NAT
SINTOMAO 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-reverse3. Falta a rota de buraco negro para o endereço global
SINTOMANenhum 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 NULL04. O endereço de destino da política de segurança é o endereço pós-NAT, não o original
SINTOMAO 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.
5. Nenhum comando mostra diretamente as contagens de acerto no server-map ou no pool de NAT
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 0Projetos de soluções relacionadas
Seis perguntas que surgem constantemente
Tiradas diretamente do campo — as que vale a pena ter uma resposta pronta.
Posso usar o próprio endereço IP da interface do roteador como o endereço global do NAT Server?
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.
Existe um comando que mostra quantas vezes o tráfego realmente atingiu uma entrada específica de NAT Server?
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.
Quando exatamente uma implantação de NAT precisa de uma rota de buraco negro?
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.
O mapeamento funciona para acesso de entrada, mas o servidor não consegue acessar a internet por conta própria — mesmo NAT Server, por que a assimetria?
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.
Nossa política de segurança referencia o servidor mapeado pelo seu IP público, e o tráfego ainda é bloqueado — por quê?
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.
Já temos um guia de configuração para Easy IP / NAT Server — quando precisamos desta nota 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ê.
Limites honestos desta nota
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.
Referências
Normas e documentos do fabricante em que esta nota se baseia. A sintaxe dos comandos segue a documentação do fabricante; verifique o comportamento exato na sua versão de firmware.
O mapeamento ainda não funciona?
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.