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 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. O SFOS suporta Custom Gateways para IPv4 e IPv6; o exemplo deste artigo utiliza IPv4.

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.

Nestes gateways criados automaticamente, a zona não pode ser alterada em Routing > Gateways. O gateway predefinido está atribuído de forma fixa à zona WAN. A zona de gateway selecionável no procedimento seguinte aplica-se aos Custom Gateways, não ao gateway predefinido.

As regras de failover de um gateway Cellular WAN são configuradas em Network > WAN link manager. Cellular WAN e failover 4G/5G explica a configuração, os alvos de teste do caminho móvel e o teste de comutação.

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. Com uma rota estática isolada, a zona do gateway não é aplicada; as zonas reais das interfaces e a regra de firewall correspondente determinam a correspondência de zonas. 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.

Os Custom Gateways existentes também podem ser editados, clonados e eliminados em Routing > Gateways. Antes da eliminação, verificar as dependências conforme descrito no procedimento de rollback mais adiante.

Escolher um Health Check que represente o caminho

O Health check está desativado por predefinição. O SFOS documenta os seguintes valores temporais predefinidos:

• Interval: Tempo entre as sondas do Health Check; valor predefinido: 60 segundos.
• Time-out: Prazo para receber resposta a uma sonda e considerar o gateway ativo; valor predefinido: 2 segundos.
• Retries: 3

Retries define o número de tentativas de verificação consecutivas. Se nenhuma receber resposta, o SFOS considera o gateway inacessível. A Sophos não fornece uma fórmula completa para o tempo exato de deteção da falha; por isso, Interval, Time-out e Retries devem ser considerados em conjunto. Protocol e IP address são, pelo contrário, decisões de desenho. Este exemplo utiliza PING para 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. Em geral, a Sophos exige como alvo um host permanentemente disponível atrás do gateway. O exemplo XFRM Any-to-Any oficial segue o mesmo princípio.

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.

Para adicionar outra Monitoring Condition, selecionar AND ou OR em Operator e clicar no ícone de adição. Definir depois o protocolo, o IP de destino e, para TCP, a porta da condição adicional. Os operadores funcionam assim:

• 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 Service, 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.

O valor predefinido do SFOS 22 para Route Precedence é static, SD-WAN, VPN. Se SD-WAN preceder Static e uma rota SD-WAN utilizar Any como destino, também pode captar tráfego interno ou diretamente ligado e interromper o acesso de gestão. O destino restrito do exemplo evita este problema. Se o desenho exigir mais do que um gateway Primary e um Backup, pode utilizar-se um SD-WAN Profile com até oito gateways.

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 zones: LAN
• Source networks and devices: 10.10.0.0/24
• Destination zones: MPLS
• Destination networks: 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 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.

Encaminhar um IP virtual por IPsec para vários servidores mostra como um local remoto acede a um IP virtual através desse gateway XFRM e de rotas SD-WAN simétricas, enquanto o DNAT distribui as ligações por vários servidores internos.

Route-based IPsec com traffic selectors específicos funciona de forma diferente: não é criada uma rota manual adicional para esses traffic selectors e o XFRM não recebe um IP próprio. Uma receita de gateway Any-to-Any não deve ser aplicada a esta variante.

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 System services > Log settings, verificar se o módulo SD-WAN está a ser registado. Em seguida, verificar no Log viewer os 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. OUT conta os pedidos e IN as respostas, desde que cada direção corresponda a Source e Destination da rota; por isso, um contador unilateral não prova, por si só, uma falha do caminho.

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. Quando o gateway Primary regressa, as novas ligações voltam a utilizá-lo; as ligações existentes permanecem inicialmente no Backup.

Por predefinição, o SFOS 22 redireciona ligações sem SNAT quando o gateway ou o SLA muda. Nas ligações SNAT, isso não acontece automaticamente. O redirecionamento com SNAT exige o mesmo IP de origem traduzido nos dois caminhos e a opção separada reroute-snat-connection; por isso, MASQ ou IPs de origem diferentes impedem muitas vezes uma comutação transparente. O teste de aceitação não 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.

XML API no SFOS 23: Para Add Gateway Object e Update Gateway Object, está documentado o estado da API 505 com o identificador de mensagem Message.GatewayIpNotInInterfaceIpRange. Trata-se do estado na resposta da API, não de um código de estado HTTP; o identificador não garante o texto exato da mensagem apresentada. Ao receber este resultado, verificar a rede da interface selecionada e o endereço do next hop previsto (Gateway IP) antes de tentar novamente. A documentação deste estado no SFOS 23 não demonstra que a validação de endereços tenha sido introduzida apenas nesta versão.

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. Se for eliminado um gateway Backup, o SFOS define o Backup da rota como None. Se for eliminado o gateway Primary ou o SD-WAN Profile selecionado, o SFOS elimina a rota SD-WAN e passa a utilizar a rota predefinida WAN link load balance.

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