Utilizar NAT em redes IPsec sobrepostas na Sophos Firewall
Se a sede e a filial utilizarem a mesma sub-rede real, nenhuma firewall consegue decidir apenas pelo destino se um pacote deve permanecer local ou atravessar o túnel IPsec. O túnel pode estar verde sem existir um caminho inequívoco. A solução é um plano de tradução coordenado em ambos os lados: cada local aparece ao peer sob uma rede traduzida única.
O tipo de túnel determina o método. IPsec policy-based e IPsec route-based com traffic selectors específicos utilizam as definições NAT diretamente na ligação IPsec. Route-based Any-to-Any utiliza regras DNAT e SNAT e uma rota para a rede remota traduzida. Configurar uma VPN IPsec Site-to-Site explica a escolha geral do tipo de túnel.
Escolher o método correto
A Sophos suporta tradução 1:1, 1:n ou n:n para IPsec policy-based. Com n:n, as redes original e traduzida têm de ter o mesmo tamanho. Por exemplo, um /24 é associado a outro /24, não a um /25.
Três perguntas bastam para escolher:
- A ligação IPsec contém Local e Remote subnets específicas? Utilizar Network address translation (NAT) na ligação.
- Ambas as sub-redes estão em
Anynum túnel route-based? Utilizar DNAT com uma regra SNAT reflexive e uma rota através de XFRM. - As redes não se sobrepõem? NAT é normalmente desnecessário e dificulta logs, regras e troubleshooting.
⚠️ Não misturar os dois métodos. Antes da alteração, guardar ambas as configurações do túnel, regras NAT e de firewall, rotas, respostas DNS e um acesso administrativo independente. Uma regra MASQ ampla ou um endereço traduzido improvisado não são workarounds seguros.
Criar um plano de endereçamento para ambos os locais
No exemplo, a sede e a filial utilizam a mesma rede real 192.168.2.0/24. Cada lado recebe a sua própria rede virtual para o túnel:
HQ real: 192.168.2.0/24 → visible to branch as 192.168.1.0/24
Branch real: 192.168.2.0/24 → visible to HQ as 192.168.3.0/24
Um cliente na sede contacta assim um servidor da filial através do endereço em 192.168.3.0/24. Um cliente da filial utiliza o endereço correspondente em 192.168.1.0/24 para um servidor na sede. O endereço real 192.168.2.x permanece local em cada local.
As três redes são valores de documentação e devem ser substituídas em conjunto por redes livres do plano real. As redes traduzidas têm de ser únicas, não podem colidir com nenhuma LAN, VLAN, VPN, rede cloud ou doméstica e devem ser documentadas de forma espelhada nas duas firewalls. Se as aplicações utilizarem nomes, o DNS de cada local deve devolver o endereço traduzido do sistema remoto.
Configurar IPsec policy-based com NAT
IPsec policy-based requer três objetos IP host em cada firewall: a rede local real, a própria rede traduzida e a rede traduzida do peer. No exemplo da sede são HO_LAN_REAL_192.168.2.0, HO_LAN_NAT_192.168.1.0 e BO_LAN_NAT_192.168.3.0.
Configurar a sede
Em Site-to-site VPN > IPsec > Add, criar a ligação como Policy-based com Gateway type Respond only. Perfil, autenticação, interface WAN e endereço do peer têm de corresponder ao lado remoto. Utilizar estas atribuições:
- Local subnet:
HO_LAN_NAT_192.168.1.0 - Remote subnet:
BO_LAN_NAT_192.168.3.0 - Network address translation (NAT): ativado
- Original subnet:
HO_LAN_REAL_192.168.2.0
A firewall traduz a rede local real para a própria rede traduzida antes do envio. O tráfego de entrada para a rede traduzida é novamente associado à rede real.
Configurar a filial de forma espelhada
Na filial, criar a ligação Policy-based com Gateway type Initiate the connection. Espelhar totalmente a atribuição:
- Local subnet:
BO_LAN_NAT_192.168.3.0 - Remote subnet:
HO_LAN_NAT_192.168.1.0 - Network address translation (NAT): ativado
- Original subnet:
BO_LAN_REAL_192.168.2.0
Local e Remote subnet contêm as redes traduzidas, enquanto Original subnet contém a rede local real. Se o tamanho ou a direção não coincidirem, pode formar-se Phase 2, mas o tráfego é traduzido incorretamente ou não encontra caminho de retorno.
Rever as regras de firewall automáticas
Com Create firewall rule, o SFOS cria regras VPN de entrada e saída. Revê-las em Rules and policies > Firewall rules, no grupo Automatic VPN rules. As regras têm de permitir as redes traduzidas na direção correta e apenas os serviços necessários. Uma regra VPN geral existente pode ser adaptada; não é obrigatória uma regra ampla separada por túnel.
As regras são avaliadas de cima para baixo. Durante um teste real, verificar Rule ID, zonas de origem e destino, redes de origem e destino, serviços e logging. Criar regras de firewall na Sophos Firewall explica a lógica geral.
Configurar route-based Any-to-Any com DNAT e SNAT
Este método requer um túnel route-based Any-to-Any funcional. A interface XFRM tem um endereço de trânsito único, existem regras LAN-to-VPN e VPN-to-LAN adequadas e uma rota estática, SD-WAN ou dinâmica aponta para a rede traduzida do peer. Só depois se adiciona NAT.
As ligações route-based com traffic selectors específicos não utilizam este procedimento. Tal como IPsec policy-based, utilizam as definições NAT da ligação IPsec. Se o tráfego corresponder antes a uma regra MASQ, o SFOS pode descartá-lo porque estas interfaces XFRM não têm endereço IP atribuído.
NAT na sede
Criar uma regra DNAT em Rules and policies > NAT rules > Add NAT rule > New NAT rule. Esta traduz pacotes de entrada destinados à rede virtual da sede para a rede local real:
- Original source: rede traduzida da filial
192.168.3.0/24 - Translated source:
Original - Original destination: rede traduzida da sede
192.168.1.0/24 - Translated destination: rede real da sede
192.168.2.0/24 - Create reflexive rule: ativado
- Load balancing method:
One-to-one
Utilizar objetos de rede ou IP range do mesmo tamanho para a associação. Depois de guardar, abrir a regra gerada Reflexive_NAT#_<DNAT_rule_name>. Na saída, tem de traduzir a rede real da sede para 192.168.1.0/24 e utilizar a rede traduzida da filial 192.168.3.0/24 como Original destination.
NAT na filial
Aplicar o mesmo princípio de forma espelhada na filial:
- Original source: rede traduzida da sede
192.168.1.0/24 - Translated source:
Original - Original destination: rede traduzida da filial
192.168.3.0/24 - Translated destination: rede real da filial
192.168.2.0/24 - Create reflexive rule: ativado
- Load balancing method:
One-to-one
A regra reflexive tem de traduzir a rede real da filial na saída para 192.168.3.0/24. Uma regra SNAT ou MASQ mais geral acima não pode capturar primeiro o tráfego. Demonstrar ordem e correspondência com NAT Rule ID e Packet Capture, em vez de as inferir apenas da lista. Compreender NAT na Sophos Firewall explica regras reflexive e o princípio first-match.
Verificar em conjunto routing, DNS e aplicações
Em cada lado, a rota para a rede remota traduzida tem de utilizar a interface XFRM correta ou o respetivo gateway monitorizado. Uma rota para a rede real idêntica seria ambígua e poderia atrair tráfego local para o túnel. Com várias rotas, verificar em conjunto Route Precedence, Administrative Distance e a seleção SD-WAN.
A aplicação também tem de utilizar o destino traduzido. Configurações estáticas, ACL, respostas DNS, monitoring e logs dos servidores não podem continuar a esperar o endereço remoto real. Um teste NAT apenas com ping não comprova que o processo de negócio funciona.
Validar o caminho em ambas as direções
Começar com um host conhecido e um serviço TCP ou UDP real em cada lado. A partir da sede, aceder ao endereço traduzido da filial e depois testar o endereço traduzido da sede a partir da filial. Para o mesmo timestamp, verificar:
- A ligação IPsec e a Child SA estão ativas.
- A Firewall Rule ID esperada permite o fluxo.
- A NAT Rule ID esperada traduz corretamente endereços originais e de destino.
- Packet Capture mostra entrada, tradução, saída XFRM e retorno.
- O servidor de destino vê o endereço de origem planeado e responde pelo mesmo caminho.
Só depois de ambas as direções funcionarem se adicionam mais hosts, serviços e nomes DNS. Packet Capture na Sophos Firewall ajuda a comparar antes e depois de NAT; Troubleshooting de IPsec na Sophos Firewall descreve a verificação completa do túnel.
Limitar os erros por sintoma
O túnel está verde, mas o destino responde localmente
O cliente utiliza provavelmente o endereço real, que também existe localmente, em vez da rede remota traduzida. Verificar a resposta DNS, o ficheiro hosts, a configuração da aplicação e a rota de destino. O erro ocorre então antes do túnel.
O caminho de ida funciona, mas falta o retorno
As traduções têm de ser espelhadas nas duas firewalls. Comparar Original e Translated source na regra reflexive, Remote subnet na ligação IPsec, gateway do servidor e regras no sentido inverso. Uma tradução unilateral não produz um fluxo bidirecional estável.
Corresponde a regra NAT errada
Verificar NAT Rule ID e ordem. Uma regra MASQ ampla, Default-SNAT ou DNAT anterior pode corresponder antes da regra VPN específica. Não desativar todas as regras NAT por tentativa; primeiro correlacionar o fluxo de teste pelo timestamp e corrigir apenas a regra em conflito.
Alguns hosts funcionam e outros não
Com n:n, os intervalos original e traduzido têm de ter o mesmo tamanho e posição. Verificar objetos IP range, máscaras, endereços excluídos, firewall do host e o offset realmente utilizado. O sucesso para .10 não comprova a associação de todo o intervalo.
Rollback e operação
Antes da alteração, preparar um backup da configuração, capturas ou exportações das configurações de túnel, NAT, firewall e routing e um acesso de gestão independente. Durante a migração, desativar regras antigas apenas quando existe um rollback inequívoco documentado.
Se a validação falhar, desativar as novas regras NAT e rotas, restaurar a configuração anterior do túnel e voltar a testar o tráfego local original. Remover as redes traduzidas de DNS, monitoring e documentação apenas quando não existir qualquer dependência.
Em operação, gerir as redes traduzidas no plano central de endereços IP. Comparar novos locais, redes cloud, pools de Remote Access e redes domésticas com as redes originais e traduzidas. Caso contrário, a sobreposição é apenas deslocada para outro ponto.