Compreendendo NAT em Sophos Firewall: SNAT, DNAT, MASQ, PAT

NAT é um dos tópicos do Sophos Firewall que rapidamente se torna confuso na prática. Os termos parecem semelhantes, a máscara de regra funciona com Original e Translated, e no Log Viewer você vê endereços diferentes do esperado dependendo da localização.

Este artigo explica os tipos mais importantes de NAT, mostra casos práticos típicos e descreve um exemplo de DNAT com uma regra de firewall adequada.

O ponto prático mais importante é: NAT deve ser considerado em conjunto com regras de firewall, roteamento, caminho de retorno e registro. Muitos problemas do NAT não surgem da tradução em si, mas da ordem incorreta das regras, de um Original destination mal compreendido, da falta de registro ou de testes da rede errada.

Orientação

Antes de construir uma regra NAT, primeiro deve ficar claro qual problema está realmente sendo resolvido. NAT traduz endereços ou portas, mas não substitui a liberação do firewall e o design de roteamento limpo.

Qual item NAT se encaixa?

NAT se sobrepõe rapidamente às regras de firewall, roteamento, WAF, VPN e Packet Capture. Dependendo da tarefa, este artigo básico nem sempre é a melhor forma de começar:

• Compreender NAT, SNAT, DNAT, MASQ, PAT, Loopback e regras reflexivas: este artigo.
• Publicar um servidor interno por encaminhamento de portas: Publicar servidor por DNAT no Sophos Firewall.
• Publicar uma aplicação HTTP ou HTTPS: Sophos Firewall WAF: publicar servidor Web em segurança.
• Classificar regras de firewall e NAT em conjunto: Compreender e configurar regras Sophos Firewall em segurança.
• Testar uma ligação individual com logs e Packet Capture: Testar regra de firewall com Log Viewer, Policy Test e Packet Capture.
• Verificar NAT para IPsec, XFRM, SD-WAN ou redes sobrepostas: Resolução de problemas IPsec VPN no Sophos Firewall.
• Analisar drops, Violation, Rule ID ou NAT Rule ID: Analisar pacotes descartados no Sophos Firewall.

Isso mantém a solução de problemas mais rigorosa: primeiro esclareça se se trata de tradução, liberação, roteamento, proteção de servidor web ou fluxo de pacotes. Depois disso, apenas a camada afetada deverá ser alterada.

NAT é tradução, não liberação

A tradução de endereço de rede altera endereços ou portas de um pacote à medida que ele passa pelo Sophos Firewall. No entanto, NAT não decide sozinho se o tráfego é permitido.

⚠️ Uma regra NAT não permite tráfego. A regra traduz apenas endereços ou portas. Uma regra de firewall adequada também é sempre necessária para o tráfego através do firewall.

Casos típicos de NAT:

• Os clientes internos acessam a Internet através do WAN-IP público.
• Um servidor interno é publicado por meio de um IP público.
• Uma porta pública é traduzida para outra porta interna.
• Redes sobrepostas são traduzidas para conexões VPN.
• Os clientes internos acessam um servidor interno através do nome DNS público.

Decisão rápida: NAT ou não NAT?

Muitos erros NAT surgem porque NAT é usado como solução padrão, mesmo que o roteamento ou uma regra de firewall sejam suficientes. Antes de cada nova regra NAT, você deve primeiro decidir se um endereço ou porta realmente precisa ser alterado.

• O cliente do LAN deverá acessar a Internet normalmente: Uma regra geral SNAT ou MASQ geralmente é suficiente.
• O servidor interno deve estar acessível pela Internet: Use DNAT ou para HTTP/HTTPS, verifique primeiro WAF.
• Uma porta diferente deve ser usada externamente e internamente: Planeje DNAT com PAT e adicione a regra de firewall apropriada.
• Usuários internos acessam o mesmo FQDN público: Verifique primeiro o DNS dividido, use o loopback NAT somente se necessário.
• Redes VPN locais e remotas são claras: Geralmente não use NAT, mas crie regras de roteamento e firewall de forma limpa.
• As redes VPN se sobrepõem ou a estação remota requer uma fonte específica: Use SNAT ou DNAT direcionado com rede de substituição documentada.
• Apenas uma regra de firewall deve ser permitida ou restrita: Não crie NAT. Ajuste a regra do firewall.

Se a resposta para “O que deve ser traduzido?” não estiver claro, uma regra NAT não deverá ser criada. Em seguida, verifique primeiro o fluxo de pacotes, endereço de destino, caminho de retorno e Log Viewer. Especialmente para VLANs internas, VPNs site a site sem redes sobrepostas e redes de servidores roteados, nenhum NAT costuma ser a solução mais limpa.

Entenda os fundamentos do NAT

A máscara de regras se torna muito mais fácil se você primeiro diferenciar entre tráfego original e tráfego traduzido. Ficará então mais claro se a origem, o destino ou o serviço precisam ser alterados.

As principais espécies NAT

• SNAT: Traduz a fonte IP. Normalmente, quando clientes ou servidores internos devem acessar a Internet com um IP público específico.
• MASQ: Traduz o IP de origem para o IP da interface de saída. Este é o caso padrão de LAN a WAN.
• DNAT: Traduz o destino IP. Isso torna um servidor interno acessível por meio de um IP público.
• PAT: Traduz porta ou serviço. Isto significa que uma porta externa aponta para outra porta interna.
• Loopback NAT: Permite acesso interno via IP público ou FQDN público. Os clientes internos usam o mesmo nome DNS que os usuários externos.
• Regra reflexiva: Cria uma regra NAT de origem reflexiva. Isto permite que um servidor publicado apareça para o tráfego de saída com uma identidade pública apropriada.

Como modelo mental ajuda: NAT não responde à pergunta “Este tráfego é permitido?”, mas sim “Como deve ser o endereço ou porta no caminho?”

Leia o original e traduza corretamente

Nas regras NAT, Original descreve o tráfego conforme ele chega ao Sophos Firewall. Translated descreve-o após a tradução.

• Original source: Endereço de origem antes de NAT.
• Translated source (SNAT): Endereço de origem para NAT.
• Original destination: Endereço de destino antes de NAT.
• Translated destination (DNAT): Endereço de destino após NAT.
• Original service: Serviço ou porta anterior a NAT.
• Interfaces e VPN: Any é frequentemente correto para interfaces de entrada e saída em cenários DNAT ou VPN, porque os túneis VPN nem sempre são tratados como interfaces físicas normais.
• Serviço traduzido (PAT): Serviço ou porta para NAT.

Se houver erros, você deve primeiro observar a aparência do pacote antes de NAT. Então você define o que o firewall deve fazer com isso.

Agendar NAT antes da alteração

Antes de fazer uma alteração NAT, você não deve apenas observar a própria regra NAT. Todo o fluxo de pacotes é crucial: onde o pacote chega, qual regra de firewall permite o tráfego, qual regra NAT o traduz, para onde vai a resposta e como o resultado é verificado?

Esses pontos devem ficar claros antes da mudança:

• Pacote antes de NAT: Origem, Destino e Serviço devem corresponder ao lado Original da regra NAT.
• Pacote de acordo com NAT: Translated source, Translated destination e Translated service devem ser definidos deliberadamente.
• Permitindo regra de firewall: NAT não permite tráfego. Sem uma regra de firewall adequada, a tradução permanece ineficaz.
• Regras NAT mais gerais: A primeira regra NAT correspondente vence. Uma regra SNAT ou MASQ ampla pode obscurecer regras mais específicas.
• Caminho de retorno: Muitos problemas do NAT são, na verdade, problemas de roteamento, caminho de retorno ou sistema de destino.
• Método de teste: Log Viewer, Rule ID, NAT Rule ID e Packet Capture devem ser preparados antes do teste.

Compreender e configurar com segurança as regras Sophos Firewall ajuda você a encontrar a regra de firewall correta. Se não estiver claro se a regra se aplica, Sophos Firewall A regra não se aplica: verificar causas é o melhor início de solução de problemas.

Exemplos práticos: Quando você usa o quê?

• Clientes do LAN deverão acessar a Internet: MASQ ou SNAT. Exemplo: 10.10.10.80 sai com o firewall WAN-IP.
• O servidor web interno deve ser acessível externamente: DNAT. Exemplo: O WAN-IP público aponta para 172.16.16.10.
• Uma porta diferente é usada externamente e internamente: PAT. Exemplo: TCP 5555 externo, TCP 443 interno.
• Usuários internos usam o mesmo FQDN que usuários externos: Loopback NAT. Exemplo: service.example.com aponta para o mesmo serviço interna e externamente.
• O servidor publicado deve aparecer de saída com IP público específico: SNAT ou Regra Reflexiva. Exemplo: Um servidor de e-mail envia com IP público definido.
• Sobreposição de redes VPN: SNAT ou DNAT. Exemplo: o site A vê o site B por meio de uma rede traduzida.
• O tráfego interno deve permanecer inalterado: Não NAT. As regras de roteamento e firewall são suficientes.

Nem todo tráfego precisa de NAT. Entre VLANs internas, em VPNs site a site sem redes sobrepostas ou em redes roteadas diretamente, NAT costuma ser até prejudicial porque logs, estações remotas e sistemas de destino perdem a fonte real IP. Portanto, um bom planejamento NAT decide primeiro se a tradução precisa ser feita.

Espécies NAT na prática

Os seguintes tipos NAT resolvem tarefas diferentes. Em ambientes produtivos, deve-se selecionar conscientemente qual tradução é necessária, em vez de usar NAT como solução geral para problemas de roteamento.

SNAT: Fonte NAT

SNAT altera o endereço de origem. O caso clássico é o acesso de saída à Internet a partir do LAN. Os clientes retêm internamente seus endereços IP internos, mas o endereço público do firewall ou um IP público definido aparece externamente.

Regra SNAT típica para LAN a WAN:

• Original source: LAN interno ou rede de servidor.
• Translated source (SNAT): MASQ ou público fixo IP.
• Original destination: Any.
• Translated destination (DNAT): Original.
• Original service: Any ou Services definido.
• Serviço traduzido (PAT): Original.
• Inbound interface: interface interna ou Any.
• Interface de saída: Interface WAN. Para ambientes simples, uma regra SNAT genérica geralmente é mais clara do que muitas regras NAT vinculadas individuais.

MASQ: Mascaramento

MASQ é uma variante SNAT conveniente. Por padrão, MASQ converte o endereço de origem no endereço IP da interface de saída. Para acesso normal à Internet, geralmente é o WAN-IP.

Na configuração básica, o Sophos Firewall possui uma regra SNAT padrão com MASQ. Se você não quiser usar esta regra, desativar geralmente é mais limpo do que excluir. Caso contrário, a regra padrão poderá reaparecer ao criar ou atualizar uma interface WAN.

Obstáculo: Com VPNs baseadas em rotas, MASQ pode parecer diferente do esperado. Se sub-redes locais e remotas forem definidas como Any ou configurações duplas IP forem usadas, o firewall poderá usar o XFRM-IP como a origem traduzida. Em Packet Capture ou tcpdump você pode ver WAN-IP no cabeçalho externo e XFRM-IP no contexto interno. Outros obstáculos se aplicam ao IPsec baseado em políticas. Se o tráfego traduzido precisar ser atribuído a um túnel IPsec específico, as rotas IPsec e a configuração Interface de saída nas regras SNAT podem ser críticas. O processo está em IPsec Criar rota em Sophos Firewall.

NAT em VPN, SD-WAN e redes sobrepostas

NAT rapidamente se torna mais complexo em ambientes VPN e SD-WAN do que o tráfego simples de LAN para WAN. O princípio mais importante permanece o mesmo: primeiro, o caminho esperado deve ser claro. Você então decide se NAT é necessário.

Cenários típicos:

• VPN site a site com redes exclusivas: Geralmente sem NAT, mas regras de firewall e roteamento limpos.
• VPN site a site com redes sobrepostas: Regra SNAT ou DNAT direcionada com rede de backup documentada.
• VPN baseado em rota com XFRM e SD-WAN: Verifique a interface XFRM, rota, rota SD-WAN e NAT juntos.
• IPsec baseado em política com tráfego traduzido: Verifique a rota IPsec e a regra SNAT com Outbound interface correspondente.
• Remote Access VPN para redes internas: Normalmente não há NAT, a menos que um sistema de destino espere uma origem específica.

Para redes sobrepostas, NAT não deve ser improvisado. Ambos os lados precisam saber qual rede real está por trás de qual rede traduzida. Caso contrário, os testes individuais funcionam, mas as aplicações, o DNS, o registo ou as regras de acesso tornam-se difíceis de compreender posteriormente. Se um túnel VPN está verde mas não passa tráfego útil, NAT é apenas uma de várias causas possíveis. Devem então ser verificados em paralelo o estado IPsec, Route Lookup, a regra de firewall, a rota SD-WAN e Packet Capture. Para um processo estruturado, use resolução de problemas IPsec VPN no Sophos Firewall, routing SD-WAN para Reply Packets e System Traffic e verificar MTU e MSS no Sophos Firewall em problemas VPN.

DNAT: Destino NAT

DNAT altera o endereço de destino. Por exemplo, você pode publicar um servidor interno por meio de um IP público ou de uma porta pública. O tráfego de entrada para o endereço WAN é traduzido para o servidor interno.

Regra DNAT típica:

• Original source: Any ou redes IP de origem definida.
• Original destination: Objeto host WAN-IP ou WAN.
• Original service: serviço externo, por exemplo HTTPS ou Synology_5555.
• Translated destination (DNAT): servidor interno.
• Serviço traduzido (PAT): Original ou porta de destino interna.
• Translated source (SNAT): principalmente Original.
• Inbound interface: Interface Any ou WAN.
• Interface de saída: principalmente Any em DNAT.

Para serviços públicos, você não deve apenas construir NAT, mas também verificar imediatamente o log, IPS, restrições de origem, lógica geo-IP e nível de patch do servidor de destino. Instruções passo a passo mais detalhadas podem ser encontradas no artigo Publicar servidor em Sophos Firewall via DNAT. Para aplicativos HTTP e HTTPS, você também deve verificar se um Sophos Firewall WAF é mais adequado do que DNAT puro. DNAT é um encaminhamento de porta. WAF pode incluir nomes de host, certificados, caminhos, perfis de proteção da web e, opcionalmente, autenticação. Para serviços simples não HTTP, DNAT geralmente permanece correto; para aplicativos da web acessíveis ao público, WAF costuma ser um ponto de partida melhor.

PAT: Tradução de endereço de porta

PAT altera o serviço ou porta. No Sophos Firewall o campo Serviço traduzido (PAT) é responsável por isso.

Exemplo:

• TCP 5555 externo para TCP 443 interno.
• TCP 20120 externo para TCP 22 interno.
• TCP 8443 externo para TCP 443 interno.

O cliente externo se conecta a uma porta pública, mas internamente é endereçada uma porta diferente. Importante: O protocolo deve estar correto. TCP pode ser traduzido para TCP, UDP para UDP. Uma conversão de TCP para UDP não é um encaminhamento de porta limpo.

Exemplo DNAT com regra de firewall

O exemplo mostra a publicação típica de um serviço interno. O que é crucial é que a regra NAT e a regra do firewall correspondam.

Exemplo prático: Publicar Synology via DNAT

No exemplo, um serviço deve ser acessível através de um WAN-IP público. O serviço Synology_5555 é endereçado externamente. Internamente, o servidor escuta HTTPS. Portanto, a regra NAT traduz o endereço de destino público para o servidor interno e o serviço público para o serviço interno.

DNAT regra campo por campo

• Rule name: Nomeie claramente, por exemplo DNAT_SYNOLOGY_5555.
• Descrição: Documente por que a regra existe e quem a criou. Isso ajudará enormemente mais tarde.
• Rule position: Regras específicas devem ser colocadas acima das regras gerais.
• Original source: Pode ser restringido na regra NAT. Na prática, muitas vezes é mais limpo manter a restrição de origem na regra de firewall para que a mesma restrição não precise ser mantida duas vezes.
• Original destination: O endereço de destino público antes de NAT. É melhor usar um objeto host para WAN-IP do que a interface WAN diretamente. Um objeto host geralmente permanece mais estável durante alterações ou ajustes na interface.
• Original service: O serviço ou porta que pode ser acessado externamente, por exemplo Synology_5555.
• Translated source (SNAT): Para regras clássicas DNAT, geralmente Original. Altere apenas se o servidor interno vir o firewall como origem. Mas então você perde o cliente real IP.
• Translated destination (DNAT): O servidor interno ou uma lista de servidores para os quais redirecionar.
• Serviço traduzido (PAT): O serviço interno ou porta a ser reescrito, por exemplo HTTPS. Se nenhuma alteração de porta for necessária, o serviço permanecerá Original.
• Inbound interface: Interface por onde entra o tráfego. Para DNAT, geralmente Any ou WAN. Any geralmente é necessário para contextos VPN porque as VPNs não são tratadas como interfaces normais.
• Interface de saída: Para DNAT geralmente Any, pois o firewall decide o roteamento e a zona de destino.

Criar regra de firewall para regra DNAT

Uma regra DNAT não é suficiente. Além disso, é necessária uma regra de firewall que permita o tráfego.

Para DNAT é importante: A regra de firewall refere-se ao tráfego no contexto DNAT. Isto parece incomum no início, especialmente com zonas-alvo e redes-alvo.

• Source zones: Principalmente WAN quando o acesso vem da Internet.
• Source networks and devices: Se possível, não Any se puder ser evitado. Melhor usar países, IPs individuais, redes, hosts ou grupos FQDN.
• Destination zones: A zona do destino interno, por exemplo SERVER ou DMZ, não simplesmente WAN.
• Destination networks: O endereço de destino público ou o objeto do host WAN de Original destination.
• Services: O serviço externo de Original service, ou seja, a porta que os clientes acessam de fora.
• Log firewall traffic: Ativar para serviços publicados. Sem registro, o Log Viewer não é útil com esta regra. Se os usuários globais precisarem de acesso e Source networks and devices não puder ser restringido de forma significativa, você ainda deverá reforçar a regra: abra apenas as portas necessárias, ative o IPS, ative o registro em log, mantenha o sistema de destino atualizado e use MFA, VPN ou ZTNA, se possível.

💡 Serviços acessíveis publicamente são frequentemente verificados muito rapidamente por bots. Sophos Firewall Threat Feeds ajudam a bloquear antecipadamente IPs, domínios ou URLs maliciosos conhecidos. Isso não substitui uma regra limpa, mas reduz significativamente o tráfego desnecessário de bots.

Regra de Loopback: Acesso interno através do nome DNS público

Uma Regra de Loopback será necessária se os clientes internos precisarem acessar um servidor interno por meio de seu IP público ou FQDN público.

Exemplo:

• Externamente, service.example.com aponta para o público WAN-IP.
• Internamente, os clientes utilizam o mesmo nome service.example.com.
• Sem loopback, o tráfego do LAN vai para o IP público do firewall e deve voltar para o servidor interno.

Em ambientes simples, o DNS dividido costuma ser mais limpo: internamente service.example.com aponta diretamente para o servidor interno IP. Então não há necessidade do Hairpin-NAT. Se o DNS dividido não for possível, uma regra de loopback pode fazer sentido.

Com o Server Access Assistant, o Sophos Firewall pode criar regras de loopback automaticamente. No entanto, isso só funciona sob certas condições, por exemplo, se a interface WAN for usada como Pública IP e as fontes externas forem definidas adequadamente em geral. Com regras manuais, o loopback deve ser planejado conscientemente e depois testado.

Regra reflexiva: espelhar o tráfego de saída do servidor

Uma Regra Reflexiva é uma regra SNAT gerada automaticamente para a regra DNAT. Esta regra pode ser útil se você quiser que o servidor publicado apareça começando com um IP público específico. Importante: As respostas normais a uma conexão DNAT de entrada geralmente não requerem uma regra reflexiva separada. O firewall com estado garante que os pacotes de resposta pertençam à conexão existente.

Você só deve ativar regras reflexivas se compreender o propósito. Em ambientes com vários IPs WAN, várias regras DNAT ou vários servidores, uma regra SNAT adicional pode resultar em um comportamento difícil de entender.

⚠️ Regras Loopback ou Reflexive geradas automaticamente continuam a ser regras independentes. Se a regra DNAT original for alterada ou eliminada mais tarde, estas regras derivadas não são atualizadas logicamente de forma automática. Após cada alteração à regra original, as regras Loopback e Reflexive associadas devem ser verificadas manualmente.

Recursos avançados NAT

Essas opções não são necessárias em todos os ambientes. Eles se tornam importantes quando os clientes internos usam o mesmo nome público, vários servidores de destino estão envolvidos ou regras NAT são criadas a partir de regras de firewall.

Server Access Assistant ou regra NAT manual?

O Server Access Assistant pode criar automaticamente regras DNAT, loopback, reflexivas e de firewall. Isso é útil se você deseja publicar um serviço rapidamente.

Para ambientes produtivos, as regras manuais costumam ser mais fáceis de entender:

• Você pode ver exatamente qual regra faz o quê.
• As restrições de origem são mantidas deliberadamente nas regras do firewall.
• A regra NAT permanece mais estreita.
• A posição da regra e o registro são definidos de forma limpa.
• As mudanças posteriores são menos surpreendentes.

O Assistente é útil, mas não substitui a compreensão das regras individuais.

Regras NAT vinculadas

Uma Regra NAT vinculada é criada a partir de uma regra de firewall. É uma regra de origem NAT na tabela de regras NAT.

Isso parece prático, mas tem limites:

• A maioria dos critérios de correspondência vem da regra do firewall.
• Na regra NAT você só pode ajustar determinados campos NAT.
• Uma regra NAT mais geral acima ainda pode corresponder primeiro.
• Muitas regras NAT vinculadas tornam a tabela NAT confusa rapidamente.

Para configurações novas e simples, uma regra NAT independente em Rules and policies > NAT rules geralmente é mais compreensível. As regras NAT vinculadas são particularmente úteis em cenários de migração ou em casos especiais muito direcionados.

Balanceamento de carga e Health Check em DNAT

DNAT pode fazer mais do que um simples encaminhamento de porta. Se vários servidores internos estiverem armazenados como Translated destination, o firewall poderá distribuir o tráfego.

Métodos possíveis:

• Round robin: distribuição simples sem persistência de sessão.
• Primeiro ativo: servidor primário com failover.
• Aleatório: distribuição aleatória.
• IP pegajoso: a mesma combinação origem-destino permanece no mesmo servidor.
• Um para um: atribuição fixa entre o destino original e o traduzido. Se você quiser que o firewall detecte se um servidor de destino está disponível, a Verificação de integridade deverá estar habilitada. Sem Health Check, o firewall considera os servidores disponíveis mesmo que não respondam.

Pedido NAT

O Sophos processa as regras NAT de cima para baixo. A primeira regra correspondente vence. Depois disso, outras regras NAT não serão mais verificadas.

Recomendação:

• Regras específicas DNAT
• Regras SNAT específicas acima das regras gerais MASQ
• Posicione a regra SNAT padrão conscientemente
• Verifique as regras NAT vinculadas regularmente
• Remova ou desative regras de migração antigas se elas não forem mais necessárias

Um pedido experimentado e testado em muitos ambientes é assim:

1. Buraco negro DNAT ou regras de bloqueio para fontes indesejadas conhecidas, se tais regras forem usadas.
2. Regras DNAT muito específicas para serviços publicados.
3. Regras SNAT especiais para servidores individuais, redes parceiras ou casos especiais VPN.
4. Loopback ou regras reflexivas quando são conscientemente necessárias.
5. Regras gerais SNAT ou MASQ para acesso normal à Internet.

Esta não é uma lei rígida e rápida, mas é uma boa estrutura de teste. O fluxo de teste específico é sempre crucial. Se uma regra MASQ ampla ou uma regra NAT vinculada antiga for colocada acima de uma regra específica, a nova regra parecerá correta, mas nunca será alcançada. Ao fazer alterações, você não deve apenas verificar a regra em si, mas também as regras diretamente acima e abaixo dela.

Para serviços públicos, uma regra de buraco negro DNAT antes da regra produtiva DNAT pode ser útil se certas listas ou países IP ruins forem interceptados antecipadamente. O processo é descrito em Sophos Firewall: Bloquear países e IPs maliciosos.

NAT altere e verifique com segurança

As alterações NAT alteram o fluxo de pacotes. É por isso que você deve tratá-la como uma mudança produtiva: preparar, testar, registrar e reverter de forma limpa, se necessário.

Implemente alterações NAT com segurança

As alterações NAT geralmente afetam o tráfego produtivo imediatamente. Isso é particularmente crítico para servidores publicados, casos especiais VPN, vários endereços WAN-IP ou regras de firewall usadas por parceiros externos. Portanto, NAT não deve ser tratado como uma pura alteração de objeto, mas sim como uma pequena alteração com um teste e um caminho de fallback.

Antes de fazer uma mudança produtiva, você deve observar brevemente:

• NAT Rule ID anterior e nome da regra: No Log Viewer você pode verificar se a nova regra realmente se aplica.
• Fluxo de teste esperado: Origem, Destino, Serviço e Direção devem estar claros antes de salvar.
• Regra de firewall dependente: NAT e a regra de firewall devem corresponder, mas devem ser verificadas separadamente.
• Caminho alternativo: Se houver problemas, a nova regra poderá ser desativada e a regra antiga poderá ser ativada novamente.
• Janela de teste: Serviços externos, sites remotos VPN ou acesso de parceiros não devem ser interrompidos despercebidos.

Ao fazer alterações importantes, recomendamos primeiro duplicar as regras NAT existentes ou criar uma nova regra específica acima delas, em vez de converter diretamente a única regra funcional. A regra antiga permanece inicialmente desativada ou permanece abaixo como referência. Após um teste bem-sucedido, ele pode ser removido ou claramente documentado.

A posição da regra também é importante: uma nova regra específica SNAT ou DNAT não terá utilidade se uma regra mais geral acima já corresponder ao mesmo tráfego. Portanto, a mudança sempre inclui um teste do visualizador de log com Firewall Rule ID e NAT Rule ID esperados. Para serviços acessíveis externamente, o teste não deve ser realizado apenas a partir do seu próprio LAN. Um teste interno para o FQDN público geralmente verifica o loopback ou o DNS dividido, mas não o acesso real da Internet. A aceitação do DNAT requer pelo menos um teste externo, por exemplo, através de comunicações móveis, um local externo ou um teste de porta controlada.

Verifique NAT e regra de firewall juntos

Um erro de pensamento comum é: “A regra NAT está correta, então deve funcionar”. Isso é apenas meia verdade.

Para que o tráfego funcione, você precisa de:

1. Roteamento para o firewall
2. regra NAT apropriada se a tradução for necessária
3. regra de firewall apropriada
4. rota de retorno correta
5. perfis de segurança apropriados
6. sem bloqueio upstream, por exemplo, roteador do provedor, grupo de segurança na nuvem ou firewall de destino O seguinte também se aplica a DNAT: As regras de firewall para tráfego DNAT usam a zona de destino após NAT, mas o endereço de destino público antes de NAT como a rede de destino. É precisamente esse ponto que é crucial em muitas soluções de problemas.

Leia Firewall Rule ID e NAT Rule ID corretamente

No caso de erros NAT, você não deve apenas verificar se existe alguma entrada de log. O que é crucial é se a entrada de log corresponde à regra de firewall esperada e à regra NAT esperada. Por esse motivo, Firewall Rule ID e NAT Rule ID são mais úteis do que apenas o nome da regra, porque os nomes podem ser alterados, escolhidos de forma semelhante ou cortados nas capturas de tela.

Uma breve interpretação ajuda:

• Firewall Rule ID esperado e NAT Rule ID esperado visível: A correspondência de regras está basicamente correta. Em seguida, verifique o caminho de retorno, o sistema de destino, o perfil de segurança e a aplicação.
• Firewall Rule ID esperado visível, mas NAT Rule ID incorreto: A regra de firewall corresponde, mas a ordem NAT ou os critérios NAT não correspondem. Verifique a posição da regra NAT, os campos Original e as regras NAT mais gerais.
• Outro Firewall Rule ID visível: Outra regra de firewall vence. Verifique a ordem das regras do firewall, zonas, origem, destino e serviço.
• Nenhum NAT Rule ID visível, embora NAT seja esperado: Nenhuma regra NAT foi aplicada ou o tipo de log ou fluxo errado está sendo visualizado. Verifique os critérios NAT, direção e fluxo de teste real.
• Nenhuma entrada de registro visível: O registro está ausente ou o tráfego não atinge o firewall. Verifique o registro de regras, roteador do provedor, VLAN, Gateway e Packet Capture. Especialmente com DNAT, um único teste bem-sucedido ou reprovado sem uma comparação de ID não é suficiente. Você deve anotar quais IDs são esperados, executar o teste exatamente uma vez e então comparar Log Viewer e Packet Capture. Se os IDs não corresponderem à expectativa, a correspondência e a ordem serão corrigidas primeiro, e não o servidor de destino.

Erros comuns NAT

Ao lidar com problemas NAT, é útil não reconstruir as regras imediatamente. Primeiramente, deve-se classificar o defeito observado.

• Nenhuma entrada de log em Log Viewer: O tráfego não alcança o firewall, o log está ausente ou o filtro está incorreto. Verifique o roteador do provedor, o grupo de segurança da nuvem, o cliente Gateway, o registro de regras de firewall e os filtros.
• Entrada de log sem NAT Rule ID esperado: A regra NAT não corresponde ou uma regra acima dela vence. Original source, Original destination, verifique o serviço e o pedido NAT.
• DNAT corresponde à regra, a conexão ainda não funciona: Regra de firewall, servidor de destino, rota de retorno ou firewall do servidor local bloqueado. Compare Firewall Rule ID, Packet Capture e logs do servidor.
• O acesso interno ao FQDN público não funciona: DNS dividido ou loopback NAT está faltando. Verifique a resolução interna do DNS e decida se o DNS dividido ou o loopback são mais limpos.
• O cliente externo vê a origem incorreta-IP: SNAT ou Regra reflexiva altera a origem inesperadamente. Verifique Translated source (SNAT) e regras geradas automaticamente.
• O tráfego VPN usa origem inesperada IP: SNAT, XFRM, rota SD-WAN ou rota IPsec não correspondem. Verifique a pesquisa de rota, rota SD-WAN, rota IPsec e posição da regra NAT.
• Porta pública apontando para serviço interno errado: PAT ou objeto de serviço está configurado incorretamente. Compare Original service e Translated service (PAT). Esta visão geral não substitui a análise de fluxo de pacotes, mas economiza tempo: separa problemas na frente do firewall, na lógica NAT, na regra do firewall e no sistema alvo.

Teste de aceitação após alterações NAT

Após uma alteração NAT, você não deve verificar apenas se um único ping ou um site funciona uma vez. O teste deve corresponder ao tipo de tradução.

Para SNAT ou MASQ:

1. Defina o cliente de teste e o serviço de destino.
2. Verifique a regra do firewall com Log firewall traffic.
3. No Log Viewer verifique quais Firewall Rule ID e NAT Rule ID estão em vigor.
4. No sistema de destino ou serviço de teste externo, verifique qual origem IP está visível.
5. Teste o caminho de retorno e o comportamento da sessão em vários links WAN.

Para DNAT ou PAT:

1. Realize o teste fora da sua rede, não apenas no LAN.
2. Compare o destino público IP, porta externa e servidor de destino interno.
3. Verifique Log Viewer Firewall Rule ID e NAT Rule ID.
4. Use Packet Capture para verificar se os pacotes chegam e continuam para o servidor interno.
5. Verifique no servidor de destino se o firewall local, o serviço e a rota de retorno estão corretos.

Para VPN-NAT:

1. Verifique o status do túnel e as associações de segurança.
2. Defina um fluxo de teste concreto com origem, destino e serviço.
3. Verifique a posição da regra NAT e a pesquisa de rota.
4. Use Packet Capture em ambos os lados se o site remoto permitir acesso.
5. Inclua logs do aplicativo ou sistema de destino para que não apenas o lado do firewall seja avaliado.

Especialmente em locais remotos, apenas um caso de teste deve ser alterado por alteração. Se a regra de firewall, NAT, a rota, SD-WAN e o sistema de destino forem ajustados ao mesmo tempo, um teste bem-sucedido dificilmente poderá ser explicado posteriormente.

Solução de problemas

Este pedido ajuda com problemas NAT:

1. Abra o Visualizador de log e filtre por Origem IP, Destino IP e Serviço.
2. Verifique quais Firewall Rule ID e NAT Rule ID são exibidos.
3. Verifique a posição de controle NAT.
4. Verifique a posição da regra do firewall.
5. Use Diagnostics > Captura de pacotes para verificar se os pacotes estão chegando e continuando.
6. Para uma análise mais profunda, verifique nat_rule.log, firewall_rule.log e fwlog.log.
7. Para contexto VPN ou XFRM, verifique também charon.log, strongswan.log e xfrmi.log. Se a regra NAT ainda não funcionar, Regra de firewall não funciona: verificar ordem, correspondência e registros e Usar ferramenta Packet Capture em WebAdmin ajudarão você a restringi-la. Quais nomes de serviço e arquivos de log são relevantes podem ser encontrados em Sophos Firewall Solução de problemas: Services e logs. Para casos de suporte, você pode exportar os logs com Sophos Firewall Salvar logs para suporte e análise.

Lista de verificação de regras NAT

• A regra NAT possui um nome e uma descrição exclusivos.
• A finalidade, o responsável e a última revisão estão documentados.
• Os campos Original e Translated foram testados em um fluxo de teste real.
• A regra NAT está acima das regras NAT mais gerais.
• Regras de firewall apropriadas estão em vigor e o registro está ativo.
• Firewall Rule ID e NAT Rule ID esperados foram verificados em Log Viewer.
• Para DNAT, a zona de destino é definida corretamente após NAT e a rede de destino antes de NAT.
• DNAT foi testado externamente, não apenas LAN interno.
• Para serviços públicos foram verificadas restrições de fonte, IPS, alternativa WAF e nível de patch.
• Para VPN-NAT, roteamento, rota IPsec, SD-WAN e redes sobrepostas estão documentados.
• Loopback ou DNS dividido é uma decisão consciente.
• As regras reflexivas só estarão ativas se o tráfego de saída do servidor realmente precisar ser espelhado.
• Regras NAT antigas ou temporárias são desativadas ou removidas.

PERGUNTAS FREQUENTES