Criar e testar um Custom Gateway no Sophos Firewall

Um Custom Gateway descreve no Sophos Firewall um next hop numa interface existente. O objeto é especialmente útil para caminhos MPLS, RED, GRE e XFRM endereçados, porque pode ter o seu próprio Health Check e a sua própria zona e ser depois utilizado numa rota SD-WAN.

Resposta rápida

O Custom Gateway é criado aqui:

Routing > Gateways > Add

Para um caminho MPLS através de Port4, por exemplo, são introduzidos estes valores:

• Name: MPLS_Zurich_GW
• Gateway IP: 192.0.2.2
• Interface: Port4-192.0.2.1
• Zone: MPLS
• Health check: On
• Monitoring condition: PING para 10.20.0.10

Depois, o gateway deve ser selecionado numa rota SD-WAN adequada e testado com a regra de firewall, o caminho de retorno, o Log viewer e tráfego real. Um ícone de estado verde confirma apenas o Health Check, não o funcionamento de toda a ligação.

⚠️ Um Custom Gateway não é um gateway WAN físico adicional. Não aparece em Network > WAN link manager e não participa no Load Balancing WAN, mesmo que lhe seja atribuída a zona WAN.

Distinguir Custom Gateway, rota e interface

Num caminho funcional, vários objetos desempenham funções diferentes:

• A interface liga a firewall à rede de trânsito, por exemplo Port4, RED ou XFRM.
• O Gateway IP é o router seguinte diretamente acessível nesse caminho.
• O Custom Gateway combina Gateway IP, interface, zona e um Health Check opcional num objeto reutilizável.
• A rota SD-WAN decide que tráfego utiliza este gateway.
• A regra de firewall permite as zonas, redes e serviços planeados.
• O lado remoto precisa de um caminho de retorno adequado.

Uma rota estática normal pode conter diretamente o Gateway IP e não precisa de um objeto de gateway separado. Um Custom Gateway torna-se útil quando o SFOS tem de monitorizar o caminho, selecioná-lo numa rota SD-WAN ou classificá-lo através de uma zona de gateway.

Por outro lado, os gateways WAN físicos são criados automaticamente quando se configura uma interface WAN e são geridos como Active ou Backup no WAN link manager. Esta separação evita que um caminho MPLS interno ou um túnel seja tratado por engano como uma ligação à Internet.

Planear a topologia de exemplo

O exemplo contínuo liga uma rede de clientes a uma rede de servidores remota através de um router MPLS:

• Rede de clientes local: 10.10.0.0/24
• Cliente de teste: 10.10.0.10
• Interface da firewall: Port4 com 192.0.2.1/30
• Router MPLS: 192.0.2.2
• Rede remota: 10.20.0.0/24
• Host estável de monitorização e teste: 10.20.0.10
• Serviço de teste: TCP 443
• Zona própria: MPLS do tipo LAN

192.0.2.0/24 é uma rede de documentação e não é utilizada em produção. No ambiente real, o IP da interface e o Gateway IP são substituídos em conjunto pela rede de trânsito efetiva. A rede remota e o host de monitorização têm de estar realmente atrás deste gateway. A zona MPLS é criada previamente em Network > Zones e protegida de acordo com o nível de confiança do caminho; zonas e interfaces no Sophos Firewall explica os princípios.

Antes da alteração, são documentadas a rota existente, as regras de firewall, a expectativa de NAT e o caminho de retorno. Uma alteração remota também requer um backup da configuração, uma janela de manutenção e um acesso de gestão independente.

Criar o Custom Gateway

Introduzir os valores básicos do gateway

1. Abrir Routing > Gateways.
2. Em IPv4, clicar em Add.
3. Introduzir MPLS_Zurich_GW como Name. O nome pode ser escolhido livremente, mas deve identificar o local e o caminho.
4. Introduzir 192.0.2.2 como Gateway IP. É o router MPLS diretamente acessível, não a rede de destino remota.
5. Selecionar Port4-192.0.2.1 como Interface. O Gateway IP e a interface devem pertencer ao mesmo caminho de trânsito acessível.
6. Selecionar MPLS como Zone.

O Sophos Firewall dá prioridade à zona do gateway sobre a zona da interface. Contudo, só a aplica ao tráfego quando o gateway está selecionado numa SD-WAN policy route correspondente. Por isso, com uma rota estática isolada, o comportamento da zona deve ser testado separadamente. A zona VPN não pode ser atribuída a um Custom Gateway.

A zona do gateway não se aplica a SD-WAN policy routes migradas do SFOS 18.0 MR1 ou de versões anteriores. Nesse caso, um campo de zona visível, por si só, não prova que uma regra existente esteja correta. Primeiro devem testar-se a rota, a correspondência da zona e o tráfego real numa janela de manutenção.

Escolher um Health Check que represente o caminho

O Health check está desativado por predefinição. Para um caminho MPLS, RED ou XFRM monitorizado, é ativado e começa-se com os valores predefinidos documentados:

• Interval: 60 segundos
• Time-out: 2 segundos
• Retries: 3
• Protocol: PING
• IP address: 10.20.0.10

O host de monitorização encontra-se deliberadamente atrás do gateway. Se apenas fosse testado o Gateway IP diretamente adjacente, o router poderia responder apesar de o caminho MPLS ou o túnel subsequente estar interrompido. Para Custom Gateways em route-based VPN, RED e MPLS, a Sophos indica expressamente um host atrás do gateway como alvo do teste.

Em alternativa, pode utilizar-se TCP com uma porta específica. Isto é útil se o teste tiver de abranger não só a acessibilidade IP, mas também um serviço que responda de forma estável. No entanto, um teste TCP na porta 443 declara o gateway indisponível quando o serviço web falha, mesmo que o routing ainda funcione. Por isso, o alvo e o protocolo de teste devem representar o sinal de failover pretendido.

Com várias Monitoring Conditions:

• AND: Todas as condições têm de ser cumpridas. É rigoroso, mas um único alvo indisponível pode provocar uma comutação desnecessária.
• OR: O SFOS verifica as condições de cima para baixo até uma ser cumprida. Isto reduz falsos alarmes, mas pode ocultar uma falha parcial.

Interval, Time-out e Retries não devem ser reduzidos sem dados. Primeiro medem-se a latência normal e as perdas temporárias de pacotes no caminho real. Valores demasiado agressivos podem fazer o estado oscilar entre ativo e inativo.

Depois de guardar, Routing > Gateways mostra através de um ícone se o Health Check considera o gateway ativo ou inativo.

Utilizar o gateway no desenho de routing

Criar uma rota SD-WAN para o tráfego de exemplo

Um objeto de gateway não encaminha tráfego por si só. Para o exemplo, é criada uma rota SD-WAN:

1. Abrir Routing > SD-WAN routes > IPv4 > Add.
2. Introduzir Clients_to_Branch_MPLS como Name.
3. Selecionar a interface interna como Incoming interface.
4. Definir Source networks como 10.10.0.0/24.
5. Definir Destination networks como 10.20.0.0/24.
6. Em Services, selecionar inicialmente apenas HTTPS, ou seja, TCP 443.
7. Em Link selection settings, utilizar Primary and backup gateways.
8. Selecionar MPLS_Zurich_GW como Primary gateway.
9. Introduzir um caminho de backup real apenas se estiver totalmente configurado e testado.
10. Definir Route only through specified gateways de forma consciente: quando está ativado, o SFOS descarta o tráfego se nenhum dos caminhos indicados estiver disponível; quando está desativado, pode assumir outra rota SD-WAN ou a rota predefinida.
11. Guardar a rota e verificar a sua posição. A primeira rota SD-WAN correspondente prevalece.

As redes e o serviço são valores específicos do ambiente. Uma rota ampla com Any como origem, destino e serviço pode abranger muito mais tráfego do que o previsto. Para o primeiro teste, a correspondência permanece restrita e só é alargada conscientemente após uma validação bem-sucedida.

Adicionar a regra de firewall e o caminho de retorno

Para o fluxo encaminhado, é criada uma regra com logging desde a zona de origem da rede de clientes até à zona de gateway MPLS. A origem, o destino e o serviço correspondem à rota SD-WAN:

• Source zone: LAN
• Source network: 10.10.0.0/24
• Destination zone: MPLS
• Destination network: 10.20.0.0/24
• Services: HTTPS
• Log firewall traffic: ativado

A zona do gateway não substitui uma regra de firewall. Inversamente, uma regra por si só também não impõe o caminho MPLS. Ambas devem corresponder à rota SD-WAN. Criar e testar regras do Sophos Firewall em segurança explica o desenho geral das regras.

O router atrás da rede remota precisa de um caminho de retorno para 10.10.0.0/24. Num routing normal entre locais, o IP original do cliente costuma ser preservado. Uma regra MASQ ampla iria ocultá-lo e poderia parecer corrigir o retorno, mas prejudicaria o desenho de routing.

Distinguir XFRM, GRE e outros caminhos de túnel

Com route-based IPsec em Any-to-Any, a interface XFRM recebe um IP de transferência. Um Custom Gateway utiliza então o IP XFRM do peer como Gateway IP, o XFRM local como Interface e um host estável na rede remota como Monitoring Target. A configuração completa do túnel permanece em Configurar uma VPN IPsec site-to-site.

Route-based IPsec com traffic selectors específicos funciona de forma diferente: o SFOS cria a rota automaticamente e o XFRM não recebe um IP próprio nem uma rota manual. Uma receita de gateway Any-to-Any não deve ser aplicada a esta variante sem verificação.

Um caminho GRE também não começa pelo objeto gateway. Primeiro, validam-se os endpoints exteriores, os IPs do túnel e o funcionamento de GRE seguindo Configurar e testar um túnel GRE na Sophos Firewall. Se o desenho do fornecedor exigir depois uma seleção SD-WAN, o Custom Gateway utiliza o IP de túnel do peer como Gateway IP. A zona, o Health Check e o match da regra têm de corresponder ao desenho concreto; a zona VPN continua indisponível para Custom Gateways.

Validar o gateway e o tráfego

Verificar o estado e a utilização

1. Em Routing > Gateways, MPLS_Zurich_GW deve aparecer ativo.
2. Atualizar Object usage e verificar se a rota SD-WAN esperada utiliza o gateway.
3. Voltar a verificar os critérios de correspondência, a posição e o gateway na rota SD-WAN.
4. Em Log viewer, verificar o módulo SD-WAN quanto a eventos de gateway, Health Check e rota.
5. Para um diagnóstico mais aprofundado, utilizar dgd.log como log de Dead Gateway Detection; serviços e ficheiros de log do Sophos Firewall explica o contexto.

O estado ativo do gateway prova apenas que o host de monitorização responde de acordo com a condição selecionada. Object Usage prova apenas a referência da configuração. Só o teste real seguinte confirma o caminho dos dados.

Testar um fluxo de tráfego real

1. A partir do cliente de teste 10.10.0.10, iniciar uma nova ligação HTTPS a 10.20.0.10.

2. Em Log viewer, verificar origem, destino, serviço, Firewall Rule ID, um eventual NAT Rule ID e o gateway utilizado.

3. Verificar o Traffic Count da rota SD-WAN.

4. Em Diagnostics > Packet capture, utilizar um filtro BPF restrito:

   host 10.20.0.10 and tcp port 443
   

5. Verificar se os pedidos saem por Port4 e se as respostas regressam pelo mesmo caminho planeado.

6. No sistema de destino, verificar o IP de origem real e o caminho de retorno.

O Policy tester não considera as rotas SD-WAN. Pode testar uma correspondência de regra de firewall, mas não o gateway realmente utilizado. Testar uma regra do Sophos Firewall com Log Viewer e Packet Capture abrange a validação combinada.

Um teste de failover só é realizado com um caminho de backup validado separadamente, numa janela de manutenção e com um acesso de gestão independente. O gateway de produção referenciado não deve ser eliminado como método de teste. Após a falha controlada do caminho, voltam a verificar-se uma nova ligação, o estado do gateway, o IP de origem público ou privado, o retorno e o failback. Não se pressupõe uma transição sem interrupções.

Delimitar sistematicamente os erros

O gateway permanece inativo

• O Gateway IP e a interface devem descrever o mesmo caminho de trânsito diretamente acessível.
• O host de monitorização deve estar realmente atrás do gateway e responder de forma fiável.
• Com PING, verificar se o ICMP é permitido em todo o caminho.
• Com TCP, verificar a porta correta e um serviço que esteja efetivamente em execução.
• Utilizar Packet Capture para verificar se a sonda e a resposta usam a interface esperada.
• Alterar Interval, Time-out e Retries apenas depois de verificar o caminho.

O gateway está ativo, mas o tráfego da aplicação não funciona

• A rota SD-WAN pode estar em falta, demasiado abaixo ou corresponder a outros valores de origem, destino ou serviço.
• A Source zone e a zona do gateway na regra de firewall devem corresponder ao fluxo real.
• Verificar separadamente Route Precedence, NAT e o caminho de retorno.
• O host de monitorização pode estar acessível mesmo que outro host ou serviço de destino esteja indisponível.
• Um gateway XFRM ativo não prova automaticamente que a SA IPsec, a regra de firewall e a rota remota estejam corretas.

A zona do gateway parece ser ignorada

• Verificar se o gateway está realmente selecionado na SD-WAN policy route correspondente.
• Com uma rota estática isolada, verificar a zona da interface e a regra de firewall que corresponde realmente.
• A zona do gateway não se aplica a uma rota SD-WAN migrada do SFOS 18.0 MR1 ou anterior. Não se deve ocultar o caminho com uma regra ampla, mas sim modernizar a rota e o modelo de zonas de forma controlada.
• A zona VPN não pode ser selecionada para um Custom Gateway. Uma interface XFRM continua a ser uma interface VPN e requer um desenho consciente de regras e routing.

O estado oscila desnecessariamente entre ativo e inativo

• Verificar a disponibilidade real e os rate limits do Probe Target.
• Medir a latência normal e a perda de pacotes antes de alterar valores.
• Com AND, um único alvo pode tornar todo o gateway inativo.
• Com OR, um alvo alternativo acessível pode ocultar uma falha parcial.
• Não utilizar intervalos ou Time-outs mais curtos como solução geral de estabilidade.

Reverter em segurança e operar o gateway

Antes do rollback, documentam-se Object Usage, a rota original e as regras de firewall originais. Em seguida:

1. Desativar a nova rota SD-WAN ou restaurar o caminho anterior.
2. Verificar com uma nova ligação de cliente se o caminho original voltou a funcionar.
3. Remover as regras de firewall ou NAT criadas apenas para o teste quando já não existirem dependências.
4. Atualizar Object Usage.
5. Eliminar o Custom Gateway apenas quando nenhuma rota ou nenhum perfil o utilizar.

Em operação, documentam-se o responsável, Gateway IP, interface, zona, Probe Targets, protocolo, Interval, Time-out, Retries, rotas que utilizam o gateway e o último teste de failover. Depois de alterações a MPLS, RED, XFRM, zonas, SD-WAN ou ao host de monitorização, voltam a testar-se o estado e o tráfego real.

FAQ