Início / Notas técnicas / Guia de solução de problemas de firewall

Falhas de sessão, NAT e política do firewall: guia de solução de problemas de campo

Quando um firewall Huawei USG “não deixa o tráfego passar”, a falha quase sempre está em um destes três lugares — a política de segurança nunca correspondeu, a tabela de sessões mostra algo anormal, ou o NAT traduziu a coisa errada. Esta é a ordem que encontra o problema mais rápido: os comandos display a executar em cada etapa, como ler o que eles retornam, e os comandos de debugging a que recorrer quando os comandos display sozinhos não bastam.

Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026

Por que a ordem importa mais do que qualquer comando isolado

Três formas de falha diferentes acabam no mesmo chamado — “o firewall não deixa o tráfego passar” — e cada uma tem sua própria ordem de diagnóstico.

Uma reclamação de tráfego de firewall raramente vem com um sintoma limpo. “Não funciona” pode significar que a política de segurança nunca correspondeu ao tráfego, que a tabela de sessões mostra algo estranho quando uma sessão já existe, ou que o NAT traduziu algo que não devia — ou não traduziu o que devia. Mudar regras na camada de política e na camada de NAT ao mesmo tempo, na esperança de acertar, é o caminho mais lento. Trabalhar as três categorias em uma ordem fixa — política de segurança, depois tabela de sessões, depois NAT — encontra a falha real mais rápido, porque cada etapa descarta um conjunto distinto de causas antes de passar para a próxima.

A seguir está essa ordem: os comandos display exatos para cada etapa e como ler o que eles retornam, os comandos de debugging e captura de pacotes a que recorrer quando os comandos display sozinhos não bastam, cinco armadilhas tiradas de casos reais de campo, e cinco respostas a perguntas frequentes construídas da mesma forma.

Leia a árvore de falhas antes de tocar em qualquer configuração

Uma falha de tráfego de firewall se divide claramente em exatamente três formas — colocar o sintoma nesta árvore primeiro indica qual seção abaixo realmente se aplica.

Cada ramo abaixo descarta uma camada específica. Trabalhar de cima para baixo — política, depois tabela de sessões, depois NAT — significa que você nunca está resolvendo problemas de NAT por ter presumido que a camada de política estava correta.

Firewall Traffic Fault 1 · Security Policy Not Matching 2 · Session Table Abnormal 3 · NAT Problem HITS stays at 0matched a higher-priority rule, or the implicit default No policy name shown at allintra-zone / Local-zone traffic — expected, not a bypass No session created at allroute missing, policy deny, blacklist, session-limit reached Session exists, one direction is 0asymmetric routing, or a downstream drop on the return path NAT rule never hitspolicy source/dest isn't the real pre/post-NAT address Translation works, traffic still dropsPAT port conflict, or an anti-attack feature discarding it

Os rótulos do diagrama permanecem em inglês para clareza técnica.

Para quem relata o problema, os sintomas de política de segurança, tabela de sessões e NAT costumam parecer idênticos — “não funciona”. Verificar os hits antes da tabela de sessões antes do NAT, nessa ordem, é o que realmente economiza tempo: cada etapa dá uma resposta conclusiva de sim ou não sobre se deve continuar.

Percorrendo cada etapa

Três categorias, três conjuntos diferentes de coisas a verificar — além dos comandos de debugging a que recorrer quando os comandos display sozinhos não bastam.

Etapa 1 — A política de segurança não corresponde

Se o contador de hits nunca se move, o tráfego não está chegando à regra que você imagina — verifique com o que ele realmente está correspondendo.

  1. Execute display security-policy rule direcionado ao destino, protocolo e porta reais do tráfego. Se HITS ficar em 0 em todas as regras, o tráfego não está correspondendo a este conjunto de regras como esperado — pode estar correspondendo a outra regra de prioridade mais alta, ou caindo na regra padrão implícita.
  2. Verifique a ordem das regras. A Huawei avalia as regras de security-policy de cima para baixo e para na primeira correspondência, então uma regra ampla com número menor pode absorver silenciosamente tráfego destinado a uma regra mais específica abaixo dela.
  3. Se a política deve reger um usuário autenticado específico, compare a zona de destino da política de autenticação com a zona de destino real da sessão — uma incompatibilidade ali significa que a sessão nunca corresponde à política de autenticação, então a regra de security-policy baseada no usuário também nunca é aplicada.
  4. Lembre-se de que o tráfego intrazona, e o tráfego de gerenciamento destinado ao próprio dispositivo sob service-manage, pode passar sem nunca mostrar um nome de política correspondente na tabela de sessões. Esse é o comportamento padrão esperado de filtragem de pacotes, não evidência de uma brecha na camada de política.
<sysname> display security-policy rule destination 1.1.1.1 protocol tcp destination-port 8888
RULE ID RULE NAME                      STATE      ACTION     HITS
-------------------------------------------------------------------------------
1       1                              enable     permit     0
2       2                              enable     permit     0
5       5                              enable     permit     0
6       6                              enable     deny       0
0       default                        enable     deny       0
-------------------------------------------------------------------------------
// HITS stays at 0 on every rule -> this traffic never reached this rule set as you defined it

<sysname> display firewall session table verbose
// cross-check the session's actual destination zone against the authentication policy's configured destination zone

Etapa 2 — Tabela de sessões anormal

Ou a sessão simplesmente não existe, ou existe com contadores que indicam exatamente qual direção está quebrada.

  1. Execute display firewall session table verbose para o fluxo exato. Se nada retornar, a falha está a montante da própria tabela de sessões — uma rota ausente ou uma negação de security-policy — não um problema da tabela de sessões.
  2. Se uma sessão existir, leia os contadores de pacotes/bytes em ambas as direções (as linhas <-- e -->). Contagens diferentes de zero em ambos os lados confirmam que os caminhos de ida e volta realmente chegam a este dispositivo — a assinatura de um fluxo saudável.
  3. Se uma direção ficar travada em 0 pacotes/bytes enquanto a outra se move, essa é a assinatura de roteamento assimétrico ou de um dispositivo a jusante descartando o tráfego de retorno — não uma falha de política local ou NAT, e não vale a pena continuar procurando neste dispositivo.
  4. Observe o campo Zone da sessão. O tráfego de controle IKE/IPSec destinado ao próprio dispositivo aparece na zona local, não na zona que você esperaria pela interface em que chegou fisicamente — uma fonte comum de confusão quando um túnel VPN compartilha o mesmo firewall.
<sysname> display firewall session table verbose source global 10.107.7.23 destination global 10.3.8.211 destination-port global 80
tcp  VPN: public --> public  ID: a38f5d6f74b701cf56ec2a0d
Zone: untrust --> trust  TTL: 00:20:00  Left: 00:17:57
Interface: Eth-Trunk0  NextHop: 0.0.0.0  MAC: 0000-0000-0000
<--packets: 10 bytes: 703 -->packets: 10 bytes: 703
10.107.7.23:47150 --> 10.3.8.211:80  PolicyName: 1
// non-zero packet count in both directions -> forward and return path both reach this device, networking is normal

// the same command on a failing flow instead shows:
<--packets: 0 bytes: 0 -->packets: 12 bytes: 840
// one direction stuck at 0 -> asymmetric routing or a downstream drop on the return path, not a local fault

<sysname> display firewall session table verbose
udp  VPN: public --> public  ID: a68f5bd4603f01f756c5ab54663
Zone: local --> trust  TTL: 00:02:00  Left: 00:01:58
// IKE/IPSec control traffic to the device itself lands in the local zone, not the interface's usual zone

Etapa 3 — Problema de NAT

As falhas de NAT tendem a se esconder em um destes três lugares: o endereço errado configurado na política, esgotamento de portas em um pool PAT, ou um recurso não relacionado descartando silenciosamente o pacote já traduzido.

  1. Confirme que o endereço configurado na security-policy é o endereço real para essa direção. Em um cenário de NAT de origem, o endereço de origem da política deve ser o endereço pré-NAT; em um cenário de NAT de destino, o endereço de destino da política deve ser o endereço pós-NAT. Configurar o lado errado desse par é invisível até você realmente rastrear uma sessão.
  2. Se a própria tradução parecer falhar intermitentemente à medida que a carga aumenta, verifique display nat port conflict em busca de um histórico de conflitos crescente ligado a um address-group específico.
  3. Lembre-se de que os pools em modo PAT permitem que um único IP público exceda o teto bruto de sessões por IP por meio da reutilização de portas, mas a probabilidade de conflito aumenta com a taxa de reutilização — a prática de campo mantém isso em aproximadamente 200.000 sessões por IP público como teto prático, não teórico.
  4. Se tanto o NAT quanto o roteamento parecerem corretos mas o tráfego ainda cair, verifique display firewall statistic system discard antes de assumir que o NAT em si é o culpado — um recurso anti-ataque (a detecção de IP-spoofing é um comum) pode descartar pacotes silenciosamente de uma forma que, de fora, parece exatamente um problema de NAT ou de sessão.
[sysname-diagnose] display nat port conflict
The history data of port conflict, Slot: 1 CPU: 0
2015-11-19 16:03:53 vsys:public protocol:17
192.168.1.1:2048[10.2.2.2:23878]-->8.8.8.8:53
pool:addressgroup1 porthash:**********

[FW] nat address-group addressgroup2
[FW-address-group-addressgroup2] mode no-pat global
[FW-address-group-addressgroup2] section 10.2.2.2
[FW-address-group-addressgroup2] route enable

<sysname> display firewall statistic system discard
Discard statistic information:
                IP header field invalid packets discarded:5
                       TCP session miss packets discarded:7
                   ATK packets discarded：77
// rising ATK-discard count with NAT/session otherwise healthy -> check anti-attack false positives, e.g. IP-spoofing detection

Pontos de depuração: quando os comandos display não bastam

Depois que as etapas acima já indicaram onde está o problema mas não o porquê, esta é a ordem para recorrer ao debugging e à captura de pacotes.

  1. Habilite primeiro terminal monitor e terminal debugging — sem os dois, a saída de debugging não será impressa em sua sessão.
  2. debugging ikev1 all / debugging ikev2 all mais debugging ipsec all restringe uma falha relacionada ao IPSec exatamente à troca de negociação, quando display ike sa / display ipsec sa sozinhos não explicam o problema.
  3. Para um fluxo específico, restrinja uma captura de pacotes a uma ACL e uma única interface em vez de capturar tudo — isso mantém o arquivo de captura legível e o custo de CPU controlado.
  4. Assim que tiver uma descoberta que valha a pena escalar, exporte um pacote completo de diagnóstico em vez de redescrever o sintoma de memória em um chamado.
<sysname> terminal monitor
<sysname> terminal debugging
<sysname> debugging ikev1 all
<sysname> debugging ipsec all

[sysname] acl 3100
[sysname-acl-adv-3100] rule 5 permit ip source 10.1.1.1 0 destination 10.2.1.1 0
[sysname] packet-capture ipv4-packet 3100 interface GigabitEthernet 1/0/1
[sysname] packet-capture startup packet-num 1500
[sysname] packet-capture queue 0 to-file 1.cap

<sysname> display diagnostic-information dia-info.txt
<sysname> save logfile all

5 armadilhas de casos reais de falha

Depois que as três etapas acima já indicaram onde está o problema, estas são as armadilhas específicas que continuam aparecendo quando você chega lá.

1. Os endereços da política de segurança devem ser o endereço real, não o que se esperaria

SINTOMAO tráfego é descartado mesmo que uma regra de security-policy pareça, no papel, permiti-lo — em um cenário onde o NAT também está configurado no mesmo caminho.

CAUSAA security-policy sempre avalia o endereço real para aquela direção, não o que parece intuitivo: em um cenário de NAT de origem, o endereço de origem da política deve ser o endereço pré-NAT, e em um cenário de NAT de destino, o endereço de destino da política deve ser o endereço pós-NAT. Configurar o lado errado desse par produz uma regra que parece correta e ainda assim nunca corresponde.

SOLUÇÃOEscreva o endereço da política com o endereço real pré ou pós-NAT, de acordo com a direção da tradução — não o endereço que um usuário ou a documentação pública do serviço referenciaria.

[FW] nat address-group addressgroup2
[FW-address-group-addressgroup2] mode no-pat global
[FW-address-group-addressgroup2] section 10.2.2.2
[FW-address-group-addressgroup2] route enable
// security-policy source-address for this flow must reference the pre-NAT address, not 10.2.2.2

2. O tráfego de zona local e intrazona pode passar sem nunca mostrar uma política correspondente

SINTOMAdefault action deny está configurado e nenhuma regra explícita de security-policy existe, mas o tráfego entre interfaces da mesma zona — ou o tráfego de gerenciamento para o próprio dispositivo — ainda passa.

CAUSAO tráfego intrazona ainda corresponde ao caminho de avaliação da security-policy, mas sob o comportamento padrão de filtragem de pacotes ele não exibe um nome de política correspondente a menos que exista uma regra detalhada com a zona de origem e a zona de destino explicitamente configuradas. Separadamente, quando service-manage enable está ativo em uma interface, o tráfego de gerenciamento destinado à zona Local ignora completamente a correspondência de security-policy — a permissão de filtragem de pacotes para ele é decidida pelo service-manage, não pelo mecanismo de política.

SOLUÇÃONão interprete “sem nome de política na sessão” como “nada está filtrando isso”. Se você precisar de visibilidade ou controle sobre o tráfego intrazona, adicione uma regra detalhada com a zona de origem e a zona de destino correspondentes explicitamente definidas; gerencie deliberadamente quais serviços estão abertos sob service-manage, já que esse caminho ignora o mecanismo de política por design.

3. Uma política baseada no usuário também precisa de uma zona de destino de política de autenticação correspondente

SINTOMAUma regra de security-policy configurada para negar o tráfego de um usuário autenticado específico não entra em vigor — o usuário está confirmado online, mas seu tráfego não está sendo bloqueado.

CAUSAA zona de destino da política de autenticação não corresponde à zona de destino real da sessão, então a sessão nunca corresponde à política de autenticação em primeiro lugar — e uma regra de security-policy baseada no usuário, a jusante disso, também nunca tem chance de ser aplicada, não importa quão corretamente esteja escrita.

SOLUÇÃOCompare display firewall session table verbose com a configuração da política de autenticação; se a zona de destino precisar cobrir mais de uma zona, defina-a como any, depois verifique novamente se a contagem de hits da regra baseada no usuário realmente começa a se mover.

4. A reutilização de portas do pool de endereços NAT tem um teto prático, não apenas teórico

SINTOMAO NAT funciona bem com carga leve, mas depois as sessões através de um pool PAT que já funcionava começam a falhar intermitentemente ou a ser descartadas à medida que o tráfego cresce.

CAUSAO modo PAT permite que um único IP público exceda seu limite bruto de 63.488 sessões por meio da reutilização de portas, mas a probabilidade de um conflito de porta aumenta com a taxa de reutilização. A prática de campo geralmente mantém isso em cerca de 200.000 sessões por IP público como um teto de trabalho, bem abaixo de qualquer máximo teórico.

SOLUÇÃOVerifique display nat port conflict em busca de um histórico de conflitos crescente antes de assumir que a configuração do pool em si está quebrada; se um único IP público estiver genuinamente sobrecarregado, adicione mais endereços ao pool ou divida o tráfego entre IPs públicos adicionais.

[sysname-diagnose] display nat port conflict
The history data of port conflict, Slot: 1 CPU: 0
2015-11-19 16:03:53 vsys:public protocol:17
192.168.1.1:2048[10.2.2.2:23878]-->8.8.8.8:53
pool:addressgroup1 porthash:**********

5. Um falso positivo anti-ataque pode parecer exatamente uma falha de NAT ou de sessão

SINTOMAUm mapeamento NAT que funcionava de forma confiável há muito tempo de repente para de funcionar, muitas vezes em um firewall de dupla saída, sem nenhuma mudança de configuração no lado do NAT ou roteamento.

CAUSAUm recurso anti-ataque — a detecção de IP-spoofing é um comum — pode começar a descartar silenciosamente pacotes que acionam sua heurística, sem nenhum sintoma na camada de NAT ou de sessão para apontar diretamente. De fora, isso se apresenta de forma idêntica a uma falha de NAT ou roteamento.

SOLUÇÃOVerifique display firewall statistic system discard em busca de uma contagem de descartes ATK crescente antes de gastar mais tempo em uma configuração de NAT ou de tabela de sessões que já está correta; desative ou ajuste o recurso anti-ataque específico uma vez confirmado, em vez de deixar o anti-ataque desativado por completo.

<sysname> display firewall statistic system discard
Discard statistic information:
                IP header field invalid packets discarded:5
                       TCP session miss packets discarded:7
                   ATK packets discarded：77

Projetos de soluções relacionadas

Segurança da borda de InternetO zoneamento do firewall, a política e a camada de NAT aos quais esta ordem de solução de problemas se aplica diretamente — não é hipotético, é o design de borda real sobre o qual esses comandos rodam. Proteção contra ransomware e segmentação de redeA segmentação de zonas depende de que o mesmo mecanismo de security-policy aqui abordado realmente aplique o que você acha que aplica — vale a pena ler depois que os fundamentos de solução de problemas estiverem sólidos.

Cinco perguntas que surgem constantemente

Tiradas diretamente do campo — as que vale a pena ter uma resposta pronta.

display firewall session table não mostra absolutamente nada para este tráfego — por onde eu começo?

Confirme primeiro a alcançabilidade da rota, depois verifique se a security-policy realmente permite o tráfego com display security-policy rule e sua contagem de HITS. Uma sessão que nunca foi criada quase sempre significa que o pacote nunca chegou ao dispositivo, ou foi negado antes mesmo que uma sessão pudesse ser criada — não um bug da tabela de sessões.

A contagem de HITS da regra que eu espero nunca aumenta. O que isso realmente me diz?

Isso significa que o tráfego está correspondendo a outra coisa — uma regra diferente de prioridade mais alta, ou a regra padrão implícita — antes mesmo de chegar à regra que você está observando. Verifique a ordem das regras e refine as condições de correspondência; uma regra com contagem de hits travada em zero raramente está “quebrada”, geralmente simplesmente não é a regra que está realmente sendo avaliada.

Por que o tráfego ainda passa quando eu não configurei nenhuma regra de security-policy e default action é deny?

Isso só se aplica ao tráfego intrazona e ao tráfego de gerenciamento da zona Local sob service-manage. O tráfego intrazona ainda é avaliado pelo mecanismo de política mas não exibe um nome de política correspondente sob o comportamento padrão de filtragem de pacotes a menos que exista uma regra detalhada; o tráfego service-manage para o próprio dispositivo ignora completamente o mecanismo de política por design. Nenhum dos dois é um bug — ambos são comportamento padrão documentado.

Qual é realmente a diferença entre um problema de tabela de sessões e um problema de política, se um chamado só diz “o tráfego não funciona”?

Nenhuma sessão em display firewall session table verbose significa que o tráfego nunca passou da camada de política — verifique os hits antes de qualquer coisa. Uma sessão que existe, com os contadores de pacotes/bytes de uma direção travados em 0 enquanto a outra se move, significa que a política já deixou o tráfego passar e o problema real é roteamento assimétrico ou um descarte a jusante — não é de forma alguma um problema de política, e não vale a pena mexer novamente na configuração da política por causa disso.

Quando devo passar dos comandos display para o debugging?

Quando os comandos display já disseram em qual etapa está travado mas não o porquê — por exemplo, uma negociação IKE que display ike sa mostra como ausente, sem razão clara do lado da política ou do roteamento. Habilite primeiro terminal monitor e terminal debugging, depois execute o comando de debugging direcionado para esse recurso (debugging ikev1 all, debugging ipsec all, etc.) junto com uma captura de pacotes restrita, e exporte um pacote completo de diagnóstico com display diagnostic-information e save logfile all antes de escalar.

Limites honestos desta nota

Limites honestos desta nota

Esta nota se baseia no conjunto de comandos de tabela de sessões, security-policy e NAT do firewall Huawei série USG, além dos casos de falha de campo por trás deles. Não cobre falhas em nível de perfil UTM (IPS, antivírus, filtragem de URL como recursos de inspeção de conteúdo em vez de correspondência de política), casos extremos de comutação de alta disponibilidade/ativo-ativo, nem em profundidade a herança de política específica de sistemas virtuais (vsys) — esses temas têm escopo suficientemente diferente para merecer tratamento próprio.

Travado em uma falha específica do firewall?

Conte-nos em qual etapa está travado — política, tabela de sessões ou NAT — junto com a saída de display security-policy / display firewall session table, e ajudamos você a interpretá-la.

WhatsApp com um engenheiro →

Leitura relacionada

Política de segurança de firewall + VPN IPSec: passo a passo de configuraçãoA configuração de referência que esta ordem de solução de problemas assume que você já tem em vigor, incluindo as regras de política que permitem o próprio tráfego do túnel. Informações de falha a coletar antes de escalarO que capturar — pacote de diagnóstico, saída de debugging, captura de pacotes — antes de repassar uma falha de firewall para um engenheiro de segunda linha. Segurança da borda de Internet empresarialO design de gateway mais amplo que esses comandos de tabela de sessões, política e NAT estão diagnosticando em primeiro lugar.
Usamos cookies apenas para análises anônimas — sem anúncios, sem rastreamento entre sites.Política de privacidade