Saltar para o conteudo
Avanet

Configurar e testar rotas SD-WAN na Sophos Firewall

Sophos Firewall

Uma rota SD-WAN controla por que gateway passa um fluxo de tráfego definido na Sophos Firewall. É útil com várias ligações à Internet, MPLS, VPNs IPsec route-based, VoIP ou serviços cloud. A rota deve ter critérios precisos e ser testada com tráfego real; caso contrário, pode abranger redes internas ou usar o Public IP errado durante o failover.

Se o Sophos Central tiver de gerar os túneis baseados em rotas e os caminhos entre locais para várias firewalls geridas, deve seguir-se Configurar e verificar um grupo de ligações SD-WAN no Sophos Central. Este artigo explica a rota SD-WAN local, que também continua importante para validar caminhos distribuídos centralmente.

Resposta curta

Uma rota SD-WAN é criada aqui:

Routing > SD-WAN routes > IPv4 / IPv6 > Add

Quatro pontos devem estar definidos previamente:

  • que tráfego deve corresponder com base em incoming interface, source, destination e service
  • que primary/backup gateway ou SD-WAN profile será utilizado
  • se apenas esses gateways são permitidos e que NAT é adequado
  • como verificar a rota, o gateway e o caminho de retorno com Log Viewer e Packet Capture

Para destinos IPv4 públicos, não se deve usar Any de forma genérica, mas sim Internet IPv4 group ou destinos específicos sempre que possível. Se SD-WAN estiver antes de Static na route precedence, uma rota Any ampla pode também enviar tráfego interno para o gateway WAN.

O vídeo complementa a instrução para planear, configurar e validar rotas SD-WAN na Sophos Firewall.

Utilização e planeamento

Quando usar SD-WAN em vez de uma rota estática

Uma rota estática é suficiente quando uma rede de destino está sempre acessível por um next hop fixo. As rotas SD-WAN acrescentam critérios como source, service, utilizador ou aplicação e podem selecionar gateways com base na disponibilidade ou qualidade.

Casos típicos:

  • encaminhar determinados clientes ou serviços por WAN2 e mudar para WAN1 em caso de falha
  • enviar VoIP ou aplicações cloud por um caminho com baixa latência e pouca perda de pacotes
  • usar MPLS, LTE/5G ou um túnel IPsec route-based como caminho primário ou de backup
  • vincular tráfego a um fornecedor cujo Public IP está autorizado num sistema remoto

Exemplo de planeamento e requisitos

Antes de criar a rota, descreve-se um fluxo concreto. Para tráfego do Microsoft 365, o planeamento pode ser:

  • Incoming interface: interface LAN interna
  • Source network: Client_Net_10.20.0.0_24
  • Destination: grupo de destinos Microsoft 365 mantido internamente ou Internet IPv4 group
  • Services: HTTPS e, se necessário, um grupo de serviços para UDP 3478-3481
  • Primary gateway: WAN2
  • Backup gateway: WAN1
  • Fallback: permitir a default route ou ativar Route only through specified gateways
  • NAT: MASQ ou IP SNAT fixo adequado ao gateway selecionado
  • Test: IP de cliente, destino, gateway esperado e entrada de log esperada

São também necessárias regras de firewall adequadas, regras NAT para tráfego que requer tradução, logging de firewall ativo e acesso a Log viewer e Diagnostics > Packet capture. Os gateways WAN encontram-se em Network > WAN link manager; os Custom Gateways para MPLS, RED ou XFRM são criados em Routing > Gateways.

O comportamento geral Active/Backup do caminho WAN predefinido é explicado em Configurar o failover WAN no Sophos Firewall; os fundamentos de interfaces e gateways encontram-se em Configurar zonas e interfaces no Sophos Firewall.

Com IPsec route-based, a direção é importante: Uma interface XFRM como Incoming interface corresponde ao tráfego que entra pelo túnel. Para tráfego LAN para VPN, seleciona-se o gateway da interface XFRM como primary gateway ou num SD-WAN profile. Os fundamentos estão em Criar rota IPsec no Sophos Firewall.

Configurar a rota SD-WAN

Definir critérios de correspondência

  1. Abrir Routing > SD-WAN routes.
  2. Selecionar IPv4 ou IPv6 e clicar em Add.
  3. Introduzir um nome inequívoco, como Clients_M365_WAN2.
  4. Selecionar a Incoming interface por onde entra o tráfego a controlar.
  5. Opcionalmente, selecionar um valor DSCP se os pacotes recebidos estiverem marcados de forma fiável.
  6. Definir Source networks e adicionar Users or groups se necessário.
  7. Limitar Destination networks tanto quanto possível.
  8. Limitar Services aos protocolos e portas necessários.
  9. Opcionalmente, selecionar Application objects.
  10. Em Link selection settings, selecionar um SD-WAN profile ou primary/backup gateways.
  11. Ativar ou desativar conscientemente Route only through specified gateways.
  12. Guardar a rota e movê-la para a posição correta; a primeira rota SD-WAN correspondente vence.
  13. Testar com um cliente e destino definidos.

Os Application Objects requerem uma Web Protection License ativa. A primeira ligação é encaminhada com base em destination IP, porta, protocolo e incoming interface por outra rota SD-WAN correspondente ou, caso não exista, pela default route. O Application Object só se aplica às ligações seguintes após a deteção da aplicação. Os dados de classificação têm uma TTL de 3600 segundos desde o início da sessão. Para Micro Apps, apenas DPI Engine Mode suporta todas as aplicações; Web Proxy Mode suporta apenas Pattern Applications e Synchronized Security Applications.

Num cluster HA, o SFOS sincroniza esta cache de Application Routing pelo link HA dedicado através de multicast 226.1.1.1 na porta 4455. Um restart da firewall elimina os dados de classificação. Depois de um restart ou de um problema HA, não se deve verificar apenas o estado do túnel ou do gateway; é necessário gerar novamente uma primeira ligação da aplicação e uma ligação seguinte.

Selecionar gateway ou SD-WAN profile

Primary/backup gateways são suficientes para um caminho preferencial e um fallback. Para usar um SD-WAN profile, criam-se pelo menos dois gateways, depois o profile em Routing > SD-WAN profiles e seleciona-se na rota. Um profile é útil com vários caminhos, load balancing ou critérios SLA:

  • First available gateway utiliza o primeiro gateway disponível na ordem definida.
  • Load balancing distribui ligações; Session Persistence e Gateway Weights controlam afinidade e distribuição.
  • Best quality compara exatamente um critério: latência, jitter ou perda de pacotes.
  • Custom SLA exige limites para os três critérios e usa a estratégia de routing selecionada se não forem cumpridos.

Os Health Checks testam por ping ou TCP até dois Probe Targets. Estes destinos devem representar o caminho relevante, mas não provam que uma aplicação completa funciona. Com Best Quality, o failback só ocorre quando o gateway original é melhor em 10 ms de latência ou em 5 ms de jitter; não existe margem equivalente para perda de pacotes.

Um profile pode conter entre dois e oito gateways. Com Load balancing, estão disponíveis Round-robin ou Session Persistence com base em source IP, destination IP, source e destination ou numa ligação individual; Gateway Weights opcionais representam diferentes capacidades das ligações. Se forem configurados dois Probe Targets, o SFOS testa primeiro o primeiro destino. Se este não responder, a firewall muda para o segundo e permanece nele enquanto responder. O simples regresso do primeiro destino não provoca uma mudança imediata.

Se Route only through specified gateways estiver ativo, a firewall descarta o tráfego quando os caminhos indicados não estão disponíveis. Sem esta opção, verifica outras rotas SD-WAN e depois a default route. Se um backup gateway for eliminado, a Sophos Firewall define-o como None; ao eliminar o primary gateway ou o SD-WAN profile, a rota é eliminada e a default route pode assumir.

Coordenar route precedence e NAT

Route precedence determina a ordem entre Static, SD-WAN e VPN. Redes diretamente ligadas e SSL VPN pertencem à categoria Static. A ordem atual é visível em Routing > SD-WAN routes ou na Device Console; alterações e rollback são explicados em Alterar route precedence no Sophos Firewall com segurança.

Routing escolhe o caminho; NAT altera endereços. Por isso, tráfego de Internet por WAN2 pode exigir MASQ ou um IP SNAT fixo nesse caminho. Em redes internas e VPNs, NAT é frequentemente indesejado. As relações são explicadas em Compreender NAT no Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Testar e aceitar a rota

Teste padrão com tráfego real

  1. Escolher um cliente de teste com IP conhecido e um destino inequívoco.
  2. Ativar logging na regra de firewall correspondente.
  3. Iniciar uma ligação real.
  4. Em Log viewer, verificar source, destination, service, rule ID, NAT ID e gateway.
  5. Verificar o traffic count da rota SD-WAN: OUT conta requests e IN replies apenas se source e destination corresponderem na direção respetiva.
  6. Em System services > Log settings, ativar o tipo SD-WAN e verificar o módulo SD-WAN no Log Viewer para eventos de profile, SLA e route.
  7. Em caso de dúvida, definir em Diagnostics > Packet capture um filtro preciso para cliente, destino e porta.

O Policy tester não considera rotas SD-WAN. Pode verificar correspondências de policy, mas não confirma a rota SD-WAN selecionada nem o gateway real. Para uma análise completa, consultar Testar regras Sophos Firewall com Log Viewer, Policy Test e Packet Capture.

Avaliar SD-WAN performance

Em Diagnostics > SD-WAN performance, seleciona-se o SD-WAN profile utilizado. Em alternativa, abre-se Routing > SD-WAN profiles, seleciona-se o profile e, em Status, clica-se em Historical performance. Para cada gateway, a vista mostra o número total de ligações, os dados transferidos, os pesos de load balancing atribuídos, bem como latency, jitter e perda de pacotes para Live, 24h, 48h, Week ou Month.

Segundo a Sophos, No data to display significa que ainda não existe uma route a utilizar o profile selecionado ou que não passa tráfego por uma route desse tipo. A mensagem não comprova, por isso, uma falha de medição. Primeiro gera-se um fluxo controlado pela route esperada e confirma-se no Log Viewer ou Packet Capture.

Reset data transfer and connection count altera os contadores. Antes de os repor, documentam-se os valores e a hora. Mesmo um gráfico sem anomalias não comprova que a regra de firewall, o NAT, a aplicação e o percurso de retorno funcionam; estes níveis continuam a fazer parte do teste real.

Testar failover e failback com segurança

Um teste de falha controlado é realizado numa janela de manutenção, com rollback documentado e um caminho de gestão independente para a firewall. Primeiro, verificar na Device Console os valores de estado atuais, apenas de leitura:

system route_precedence show
show routing reroute-connection
show routing reroute-snat-connection

Depois, iniciar tráfego real da aplicação, provocar de forma controlada a indisponibilidade do primary gateway e verificar caminho, sessões, Public Source IP e retorno. Não se devem eliminar o primary gateway nem o SD-WAN profile para este teste, porque isso remove a rota e testa apenas o fallback para a default route. Editar a route ou o profile, ou alterar Route Precedence, também pode redirecionar ligações existentes e não deve fazer parte do mesmo teste de referência. Com seleção direta primary/backup, as novas ligações voltam ao primary quando regressa; as ligações existentes permanecem geralmente no backup gateway.

reroute-connection está ativo por predefinição e aplica-se a ligações sem SNAT. Ligações SNAT não são redirecionadas por predefinição; mesmo com reroute-snat-connection ativado separadamente, só funciona se ambos os caminhos usarem o mesmo Source IP traduzido. Com MASQ ou endereços Override Source Translation diferentes, a ligação SNAT não é redirecionada e a sessão existente termina quando o caminho falha.

Diagnosticar problemas sistematicamente

A rota não corresponde

  • Comparar incoming interface, source network, destination e service com o fluxo real.
  • Verificar a ordem; a primeira rota SD-WAN correspondente vence.
  • Para Application Objects, verificar licença, deteção DPI e uma segunda ligação após a classificação.
  • Não usar o traffic count como única prova, porque requests e replies só são contados quando os critérios source/destination correspondem.
  • Com Direct Web Proxy, um service HTTP/HTTPS não é suficiente: usar Any ou um service para a porta definida em Web > General settings > Web proxy listening port. Neste caso especial, source network e incoming interface não correspondem para reply packets; o retorno do proxy precisa também de um WAN default gateway ou de uma rota estática adequada.
  • Numa rota SD-WAN migrada do SFOS 17.5 ou anterior, verificar se a regra de firewall original foi eliminada. Estas rotas migradas permanecem associadas à regra antiga e também são removidas quando essa regra é eliminada.
  • Em IPv6, o Dead Gateway Detection nas rotas SD-WAN não monitoriza tráfego de rede de terceiros, como SNMP. A ausência de uma medição externa não constitui, por isso, uma prova fiável do estado DGD.

Configurar o Direct Web Proxy com um ficheiro PAC descreve o listener, a distribuição aos clientes, a regra de proteção e o teste com tráfego real.

Para reply packets e system-generated traffic aplicam-se switches e regras de correspondência próprios. Estes casos são explicados em Verificar SD-WAN routing para reply packets e system traffic no Sophos Firewall.

O tráfego segue o caminho errado

  • Para destinos IPv4 públicos, substituir Any por Internet IPv4 group ou destinos concretos.
  • Verificar route precedence, sobretudo se estiverem envolvidas redes internas, SSL VPN ou IPsec policy-based.
  • Verificar estado de gateway e SLA, bem como Health Check Targets.
  • Comparar a regra NAT e o Source IP traduzido com o gateway realmente utilizado.
  • Verificar se um primary gateway ou SD-WAN profile foi eliminado, removendo também a rota.

A aplicação ou resposta falha após o failover

Primeiro, usar Packet Capture para verificar se o pacote sai pelo gateway esperado e se a resposta regressa. Depois, verificar NAT, allowlists de IP públicos, Session Persistence, MTU/MSS e o estado do caminho VPN ou MPLS. SIP/RTP, portais bancários e APIs com Source IP fixo devem ser testados especialmente com tráfego real da aplicação.

Se o problema começou após uma atualização de firmware, consultar as notas de versão atuais do SFOS 22.0 antes de fazer alterações extensas nas regras. O SFOS 22.0 MR1 corrige, entre outros problemas, interrupções aleatórias de SD-WAN e áudio unidirecional através de VPN route-based com SD-WAN routing.

Operação e documentação

Para cada rota SD-WAN em produção, documentar objetivo, incoming interface, source/destination, services, gateway ou profile, fallback, comportamento NAT esperado, cliente de teste, destino de teste, owner e data de revisão. Após alterações de fornecedor, VPN, interface ou serviço cloud, verificar novamente correspondência, logs e failover.

Uma rota só é aceite quando:

  • os critérios de correspondência abrangem apenas o tráfego planeado
  • regra de firewall, NAT e route precedence correspondem ao design
  • Log Viewer e Packet Capture confirmam o caminho esperado
  • failover, failback e Public Source IP reagem conforme documentado
  • estão definidos um responsável e a próxima data de revisão