Encaminhar um IP virtual por IPsec para vários servidores

Um IP virtual pode apontar para vários servidores internos através de um túnel IPsec baseado em rotas existente. O local remoto utiliza apenas um endereço de destino estável. A Sophos Firewall encaminha o tráfego pela interface XFRM e traduz depois o endereço virtual para uma lista de servidores através de DNAT.

Não se trata de um DNAT normal da Internet: túnel, endereços XFRM, rotas SD-WAN, regras VPN e NAT têm de funcionar como um único caminho nas duas firewalls.

Procedimento resumido

1. Validar um túnel baseado em rotas Any-to-Any com interfaces XFRM endereçadas nas duas firewalls.
2. Criar um gateway para cada endereço XFRM do peer.
3. Configurar rotas SD-WAN simétricas para a rede remota, as redes locais e o IP virtual.
4. Criar regras de firewall restritas para a origem remota, o IP virtual e o serviço necessário.
5. No lado dos servidores, criar uma regra DNAT do IP virtual para uma lista de servidores com Round-robin.
6. Verificar várias ligações novas através de Log Viewer, Rule IDs, NAT Rule ID e Packet Capture.

⚠️ Uma ligação IPsec verde ou um gateway XFRM ativo ainda não provam que o DNAT e a rota de retorno funcionam. Antes da mudança em produção, o fluxo real da aplicação tem de poder ser seguido nas duas direções.

Quando este design é adequado

Este procedimento é adequado quando hosts num local remoto precisam de aceder a um serviço interno através de um endereço virtual fixo, mantendo ocultos os endereços reais dos servidores. Uma lista de servidores pode, por exemplo, distribuir novas ligações por dois servidores de aplicações equivalentes.

Para uma única ligação direta a um servidor conhecido, normalmente basta uma rota comum com uma regra de firewall. Se um serviço precisar de ser publicado na Internet, aplica-se antes o procedimento DNAT ou WAF clássico. O planeamento geral do túnel é explicado em Configurar uma VPN IPsec Site-to-Site.

Este design não é adequado para IPsec baseado em políticas nem para túneis baseados em rotas com Traffic Selectors específicos. O caminho descrito requer um túnel baseado em rotas com Any como redes local e remota, interfaces XFRM endereçadas e encaminhamento explícito.

Topologia de exemplo

No exemplo, clientes de 192.168.3.0/24 acedem ao endereço virtual 10.10.10.1. Os servidores 172.16.16.2 e 172.16.16.3 estão atrás da Firewall 1. Os endereços de transferência XFRM são 10.255.255.1/30 e 10.255.255.2/30.

Remote clients                 Route-based IPsec                 Server site
192.168.3.0/24  →  xfrm2 10.255.255.2  ⇄  10.255.255.1 xfrm1  →  VIP 10.10.10.1
                                                                        │ DNAT
                                                        ┌───────────────┴───────────────┐
                                                        172.16.16.2           172.16.16.3

Todos os endereços são valores de exemplo e são substituídos pelas redes reais. Os endereços XFRM têm de formar uma rede de transferência dedicada que não seja utilizada noutro local. O IP virtual não pode sobrepor-se a um host real, interface, rede VPN ou outra publicação NAT.

Preparar o túnel e XFRM

Túnel Any-to-Any e endereços de transferência

Na Firewall 1, o túnel é criado como Route-based (Tunnel interface) com Respond only; na Firewall 2 utiliza-se Initiate the connection. Nos dois lados, Local subnet e Remote subnet ficam em Any.

Em seguida, as interfaces XFRM recebem os endereços de transferência em Network > Interfaces:

• Firewall 1, xfrm1: 10.255.255.1/30
• Firewall 2, xfrm2: 10.255.255.2/30

Os parâmetros de Phase 1 e Phase 2, IDs e autenticação já têm de estar validados. Os endereços XFRM não são alterados num túnel de produção que não tenha sido testado.

Criar gateways XFRM

Para as rotas SD-WAN, cada firewall precisa de um gateway para o endereço XFRM do peer:

• Firewall 1: Gateway IP 10.255.255.2 através de xfrm1
• Firewall 2: Gateway IP 10.255.255.1 através de xfrm2

O estado do gateway verifica apenas o Monitoring Target selecionado. Criar e validar um Custom Gateway explica completamente o objeto, o Health Check e o teste funcional.

Criar regras e rotas SD-WAN

Firewall 1 no local dos servidores

A regra de firewall de entrada permite apenas o fluxo previsto:

• Source zone: VPN
• Source networks and devices: 192.168.3.0/24
• Destination zone: Any, como no exemplo da Sophos para o endereço virtual
• Destination networks: 10.10.10.1 e outras redes locais apenas se forem necessárias
• Services: apenas o serviço da aplicação, por exemplo HTTPS
• Log firewall traffic: ativado

Any em Destination zone não justifica origens, destinos ou serviços abrangentes. O IP virtual não está atribuído a uma interface normal. Por isso, a Rule ID tem de ser confirmada com tráfego real.

A rota SD-WAN na Firewall 1 envia o tráfego de retorno para a rede remota através do gateway XFRM. Em Source networks introduzem-se as redes locais realmente necessárias e 10.10.10.1; em Destination networks, 192.168.3.0/24.

Firewall 2 no local remoto

A regra de saída utiliza LAN como Source zone e VPN como Destination zone. A origem é 192.168.3.0/24, o destino inclui pelo menos 10.10.10.1, o serviço corresponde à aplicação e o logging permanece ativo durante a introdução.

A rota SD-WAN na Firewall 2 envia tráfego de 192.168.3.0/24 para 10.10.10.1 através do gateway XFRM. Route only through specified gateways impede um caminho alternativo por outra rota quando o serviço só pode estar acessível por este túnel.

A decisão sobre esta opção faz parte do plano de falha. Sem ela, outra rota pode assumir o tráfego; com ela, o SFOS descarta o tráfego quando o gateway especificado não está disponível. Criar e testar uma rota SD-WAN explica a configuração completa.

Traduzir o IP virtual para a lista de servidores com DNAT

Na Firewall 1, criar uma regra direcionada em Rules and policies > NAT rules > Add NAT rule > New NAT rule:

• Original source: 192.168.3.0/24
• Translated source: Original
• Original destination: 10.10.10.1
• Original service: o serviço real da aplicação, por exemplo HTTPS
• Translated destination: objeto de lista de servidores com 172.16.16.2 e 172.16.16.3
• Translated service: Original
• Load balancing method: Round-robin

O DNAT não permite tráfego por si só. A regra de firewall, a rota SD-WAN e a rota de retorno continuam a ser requisitos separados. Compreender NAT na Sophos Firewall explica os valores originais e traduzidos e a ordem das regras.

Round-robin distribui novas ligações correspondentes pelos membros da lista de servidores. Um canal de browser ou aplicação reutilizado não é, por isso, um teste de distribuição válido. O método de seleção também não prova automaticamente a saúde da aplicação em cada backend. Testar os dois servidores separadamente com sessões novas.

Validar o caminho completo

Antes do teste, documentar o estado do túnel, os endereços XFRM, o estado dos gateways, a posição das rotas SD-WAN e as Rule IDs. Em seguida, criar várias ligações novas da aplicação a partir da rede remota para o IP virtual.

No Log Viewer têm de estar visíveis a origem 192.168.3.0/24, o destino 10.10.10.1, a Firewall Rule ID esperada e a NAT Rule ID. O Traffic Count da rota SD-WAN tem de aumentar. Um Packet Capture restrito mostra se os pacotes chegam à interface XFRM, são enviados ao servidor selecionado após o DNAT e regressam pelo mesmo túnel.

O teste é repetido com os dois backends. Nos servidores, verificar o endereço de cliente esperado, o serviço e a rota de retorno. Um ping ao IP virtual não substitui um teste real de HTTPS, SAP ou outra aplicação.

Testar uma regra de firewall com Log Viewer e Packet Capture ajuda na verificação conjunta da regra, NAT e caminho dos pacotes.

Delimitar erros sistematicamente

O túnel está verde, mas o IP virtual não responde

Verificar primeiro a rota SD-WAN na Firewall 2: origem, destino, serviço e gateway XFRM correspondem? Depois, verificar a Rule ID e a NAT Rule ID na Firewall 1. Se faltar a NAT Rule ID, Original source, Original destination, serviço ou posição da regra não correspondem.

O DNAT corresponde, mas o servidor não responde

Verificar o objeto de lista de servidores, o serviço local e o gateway do servidor. A rota de retorno tem de passar pela Firewall 1 para que a sessão NAT existente volte a traduzir a resposta para 10.10.10.1. Não adicionar uma regra MASQ abrangente como atalho, pois pode falsear o diagnóstico.

Apenas um servidor recebe ligações

Utilizar várias sessões realmente novas e fechar as ligações Keep-alive existentes. Depois, comparar a lista de servidores, Load balancing method e NAT Rule ID. Se um backend não funcionar diretamente, corrigir primeiro o respetivo serviço ou caminho local.

O tráfego utiliza outra rota

Verificar a posição e o Traffic Count das rotas SD-WAN e os gateways XFRM selecionados. O Policy Tester não considera totalmente as rotas SD-WAN; utilizar em conjunto Log Viewer, Route lookup e Packet Capture.

Repor com segurança

Antes da alteração, documentar o backup da configuração, o estado do túnel, os endereços XFRM, os objetos gateway, as regras e as rotas. Se o novo caminho não funcionar:

1. Desativar a nova regra DNAT.
2. Desativar as duas novas rotas SD-WAN.
3. Repor as regras de firewall específicas no estado anterior.
4. Remover gateways XFRM e endereços de transferência apenas se nenhuma outra rota os utilizar.
5. Voltar a testar o túnel e o fluxo da aplicação originais.

Não eliminar um gateway ou uma interface XFRM enquanto Object usage ainda mostrar dependências. Backup e restauro da Sophos Firewall explica o processo seguro de backup e recuperação.

FAQ