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 escolhidas, regras VPN e NAT têm de funcionar como um único caminho nas duas firewalls.
Procedimento resumido
- Validar um túnel baseado em rotas Any-to-Any com interfaces XFRM endereçadas nas duas firewalls.
- Se for utilizado SD-WAN, criar em cada firewall um gateway para o endereço XFRM do peer.
- Encaminhar o
VIP-App(198.51.100.10/32) e a rede cliente para XFRM com rotas estáticas, dinâmicas ou SD-WAN conforme a arquitetura existente. - Criar regras de firewall restritas para a origem remota, o IP virtual e o serviço necessário.
- No lado dos servidores, criar uma regra DNAT do IP virtual para uma lista de servidores com Round-robin.
- 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. Criar primeiro um backup da configuração e documentar o estado inicial. 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 procedimento específico requer um túnel baseado em rotas com Any como redes local e remota, interfaces XFRM endereçadas e encaminhamento explícito. Um túnel baseado em rotas com Traffic Selectors pode atingir o mesmo objetivo, mas a SFOS cria as rotas a partir dos seletores; os passos de gateway XFRM não se aplicam sem alterações. Este procedimento não se aplica a IPsec baseado em políticas.
Topologia de exemplo
No exemplo, clientes de 192.0.2.0/24 acedem ao endereço virtual 198.51.100.10. Os servidores 10.0.20.21 e 10.0.20.22 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.0.2.0/24 → xfrm2 10.255.255.2 ⇄ 10.255.255.1 xfrm1 → VIP 198.51.100.10
│ DNAT
┌───────────────┴───────────────┐
10.0.20.21 10.0.20.22
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.
O exemplo preserva os endereços dos clientes com Translated source (SNAT): Original. Por isso, ambos os backends precisam de um caminho de retorno para 192.0.2.0/24 através da firewall dos servidores. Se tal não for possível, poderá ser necessário um SNAT planeado; este oculta o endereço do cliente e não é uma correção geral para routing incorreto.
192.0.2.0/24 e 198.51.100.0/24 são redes de documentação; 10.0.20.0/24 é a rede de servidores do exemplo.
Preservar o estado inicial
Antes de qualquer alteração, criar um backup da configuração e registar o estado do IPsec, os endereços XFRM, a ordem de routing e SD-WAN, os Rule IDs de firewall e NAT, os contadores existentes e os gateways predefinidos dos backends. Não utilizar sessões já estabelecidas como teste.
Criar os objetos IP
Na firewall dos servidores, abrir Hosts and services > IP host > Add. Criar VIP-App com IP version IPv4, Type IP e o endereço virtual, e Remote-Clients com Type Network. Criar App-Backends com Type IP list e os endereços dos servidores separados por vírgulas. Na SFOS 22, uma IP list aceita até 800 endereços e não pode pertencer a um IP host group. Utilizar a lista diretamente como Translated destination (DNAT).
Os valores concretos dos objetos do exemplo são:
VIP-App: IP versionIPv4, TypeIP, IP address198.51.100.10.Remote-Clients: TypeNetwork, IP address192.0.2.0, Subnet/24.App-Backends: IP versionIPv4, TypeIP list, IP addresses10.0.20.21,10.0.20.22.
Definir as rotas do túnel
As rotas SD-WAN seguintes só são necessárias se SD-WAN já for o método de encaminhamento escolhido. Um túnel Any-to-Any também pode usar rotas estáticas ou dinâmicas: no local cliente, encaminhar o VIP-App (198.51.100.10/32) para XFRM; no local dos servidores, Remote-Clients para XFRM. Não inferir nem duplicar rotas sem verificar a route precedence existente.
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.
Se o SD-WAN já for o padrão de routing
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.2através dexfrm1 - Firewall 2: Gateway IP
10.255.255.1através dexfrm2
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.
A rota SD-WAN na Firewall 2 envia tráfego de 192.0.2.0/24 para 198.51.100.10 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.
A Firewall 1 tem de possuir uma rota efetiva para 192.0.2.0/24 através de XFRM. Não pressupor que uma rota SD-WAN simétrica trata as respostas: as rotas SD-WAN só se aplicam a reply packets quando set routing sd-wan-policy-route reply-packet enable está ativo. Verificar esta definição global ou utilizar o encaminhamento estático ou dinâmico existente.
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:
- Rule name:
DNAT-VPN-VIP-App - Rule position: acima de regras NAT mais amplas que também possam corresponder
- Original source:
192.0.2.0/24 - Translated source:
Original - Original destination:
198.51.100.10 - Original service: o serviço real da aplicação, por exemplo
HTTPS - Translated destination: objeto de lista de servidores com
10.0.20.21e10.0.20.22 - Translated service:
Original - Inbound interface / Outbound interface:
Any(obrigatório nos campos NAT para tráfego VPN) - Load balancing method:
Round robin - Health check: ativo, Probe method
TCP, Port443
O DNAT não permite tráfego por si só. A regra de firewall, a rota de túnel escolhida 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.
Round robin envia os novos pedidos sequencialmente. Sem Health check, a SFOS considera todos os membros disponíveis e pode escolher um servidor inativo. Definir Probe interval, Response time-out e Deactivate host after; uma sonda TCP não substitui o teste da aplicação. O NAT aplica-se apenas ao primeiro pacote: uma alteração não move sessões estabelecidas e deve ser testada com novas ligações.
Criar a regra de firewall correspondente
A regra de saída utiliza LAN como Source zone e VPN como Destination zone. A origem é 192.0.2.0/24, o destino é 198.51.100.10, o serviço corresponde à aplicação e o logging permanece ativo durante a introdução.
A regra de firewall de entrada permite apenas o fluxo previsto:
- Rule name:
Allow-VPN-VIP-App - Rule position: acima de regras sobrepostas
- Action:
Accept - Source zone:
VPN - Source networks and devices:
192.0.2.0/24 - Destination zone: zona dos backends traduzidos,
LANneste exemplo - Destination networks: apenas
198.51.100.10 - Services: apenas o serviço da aplicação, por exemplo
HTTPS - Log firewall traffic: ativado
A SFOS procura primeiro o DNAT e utiliza depois na regra de firewall a zona do destino traduzido. Destination networks continua a ser o VIP original. Confirmar a posição e a Rule ID com tráfego real.
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, confirmar a origem, a Firewall Rule ID esperada e a NAT Rule ID. Comparar o VIP antes do NAT com o backend traduzido através de um Packet Capture restrito; não inferir a tradução de um campo de destino ambíguo. A captura também mostra a entrada por XFRM e o retorno pela mesma firewall.
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
Sem NAT Rule ID
Verificar Original source, VIP-App, HTTPS e a posição da regra NAT. Confirmar também que nenhuma regra NAT anterior corresponde primeiro. Criar uma nova ligação após uma correção, pois as sessões existentes não são reavaliadas pelo NAT.
O DNAT corresponde, mas a regra de firewall não
As Destination zones devem corresponder à zona dos endereços backend traduzidos, não ao VIP nem genericamente a VPN. Destination networks continua a ser VIP-App. Verificar novamente o Rule ID e o evento de descarte no Log Viewer.
Um backend continua inacessível
Comparar o estado do Health Check, o método de probe e a porta com o serviço real. Sem Health Check, o SFOS pode selecionar um membro em falha. Mesmo um probe TCP bem-sucedido não valida a aplicação, TLS ou autorização; testar o backend diretamente na rede dos servidores e depois através de uma nova sessão VIP.
A resposta segue o caminho errado
Verificar o gateway predefinido ou a rota específica do backend, a rota para Remote-Clients e o Packet Capture na firewall dos servidores. Não adicionar uma regra MASQ ampla como atalho de diagnóstico. Com SD-WAN, verificar também posição, route precedence, monitoring e Route only through specified gateways.
Repor com segurança
Desativar primeiro o DNAT para impedir novas sessões e deixar terminar ou encerrar as existentes na janela de manutenção. As alterações NAT não são reavaliadas para uma ligação estabelecida. Desativar depois apenas as regras e rotas criadas para este caminho e repor a ordem documentada.
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:
- Desativar a nova regra DNAT.
- Desativar apenas as rotas estáticas ou SD-WAN criadas para este caminho.
- Repor as regras de firewall específicas no estado anterior.
- Remover apenas os gateways novos e os endereços XFRM recém-atribuídos quando não existirem dependências.
- Voltar a testar o túnel e o fluxo da aplicação originais.
Não eliminar um gateway enquanto Object usage ainda mostrar dependências. A interface XFRM é criada pelo túnel; não eliminar um túnel existente que transporte outras redes. Backup e restauro da Sophos Firewall explica o processo seguro de backup e recuperação.