Configurar e testar rotas SD-WAN na Sophos Firewall

29. OUTUBRO 2026 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 Fusion (anteriormente 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 Fusion. 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.

Para um exemplo Teams mais restrito, adicionar o grupo fictício Sales_Team em Users or groups e Teams_VoIP em Application objects. Substituir ambos os nomes pelo grupo de utilizadores próprio e pelas aplicações efetivamente necessárias. Com a interface LAN, Client_Net_10.20.0.0_24, os destinos e serviços previstos, estes critérios encaminham apenas o fluxo correspondente por WAN2/WAN1. Verificar separadamente uma regra de autorização restrita de LAN para WAN para esta origem, destinos e serviços, as permissões de utilizador pretendidas e NAT nos dois caminhos. A rota SD-WAN não concede acesso; o teste deve confirmar o utilizador, a aplicação, Firewall Rule ID e NAT ID previstos.

Duas WAN com prioridades opostas

Para a LAN 10.20.0.0/24, os destinos públicos selecionados devem usar preferencialmente WAN1, e os restantes destinos IPv4 públicos, WAN2. Cada ligação serve de reserva à outra. Este exemplo de planeamento complementa o procedimento SFOS-22; a documentação SFOS-23-EAP confirma o mecanismo dos perfis, mas não constitui aprovação para qualquer build.

⚠️ As novas rotas e a sua ordem alteram o caminho dos dados. Primeiro, guardar posições das rotas, estados On/Off, valores dos perfis, NAT e a Route Precedence atual, e verificar acesso de administração independente. Efetuar testes de falha apenas numa janela de manutenção aprovada; não eliminar nem alterar gateways ou perfis partilhados para simular falhas.

Em Routing > SD-WAN profiles > Add, criar dois perfis separados com Routing strategy: First available gateway: Ziele_WAN1_WAN2 pela ordem WAN1, WAN2, e Internet_WAN2_WAN1 pela ordem WAN2, WAN1. Nomes, LAN e gateways são valores de exemplo ajustáveis. Ativar Health check em ambos; manter SLA desativado nesta seleção baseada apenas na disponibilidade. Escolher alvos das sondas, protocolo e contadores segundo o procedimento de verificação de estado abaixo, sem aceitar cegamente os valores predefinidos. Os alvos devem detetar também falhas para lá do gateway do operador, não apenas a sua acessibilidade local.
Em Routing > SD-WAN routes > IPv4 > Add, criar a rota específica LAN_Ziele_WAN1: Incoming interface é a interface LAN real, Source networks o objeto de 10.20.0.0/24, Destination networks o grupo atualizado de destinos públicos selecionados e Services apenas os serviços necessários. Selecionar Ziele_WAN1_WAN2. Para domínios, considerar primeiro os limites de hosts e grupos FQDN; um domínio não garante uma gama exclusiva de IP de destino.
Abaixo, criar LAN_Internet_WAN2 com a mesma interface LAN e rede de origem, Destination networks: Internet IPv4 group, os serviços de Internet aprovados e Internet_WAN2_WAN1. A rota específica deve ficar acima da rota geral de Internet. Não usar uma rota global Any; os destinos internos e VPN não pertencem a este caminho de Internet.
Definir conscientemente Route only through specified gateways para ambas: neste exemplo está ativado para que nenhum outro caminho assuma o tráfego se ambos os previstos falharem. Verificar separadamente permissões de firewall e MASQ/SNAT para as duas WAN. Se o destino remoto exigir um IP público fixo, também terá de permitir o IP de reserva.

Para validar, criar uma ligação nova a um destino específico e a outro destino público: inicialmente esperam-se WAN1 e WAN2, respetivamente. Depois, testar separadamente ambas as falhas a montante num ambiente aprovado, incluindo com a interface física ainda ativa: se WAN1 falhar, as novas ligações das duas classes devem funcionar por WAN2; se apenas WAN2 falhar, por WAN1. Após cada reposição, comparar novas ligações com a prioridade prevista e observar as sessões existentes separadamente. Comprovar rota, gateway e SNAT/IP público nos logs ou no Packet Capture, e voltar a verificar DNS, HTTPS e acesso de administração interno. Isto não implica um tempo fixo de comutação nem continuidade das sessões existentes.

Perante um caminho inesperado, não alargar critérios: comparar primeiro correspondências de rotas, ordem, estado e NAT. Para reverter, desativar as novas rotas ou repor os valores anteriores documentados de rotas, perfis e NAT, incluindo a ordem; depois, verificar novamente o estado e os dois fluxos de teste. Sem uma simulação de falha isolável, essa parte da validação fica pendente. Os limites detalhados de sessões e SNAT encontram-se abaixo na secção sobre Testar failover e failback com segurança.

MPLS entre uma filial e a sede

Um exemplo delimitado liga 10.20.0.0/24 na filial aos servidores web da rede da sede 10.30.0.0/24: a interface de entrada é a LAN da filial, o primary gateway é MPLS-1, o backup é MPLS-2 e os serviços limitam-se aos TCP 80/TCP 443 necessários. A firewall da sede precisa da rota de retorno correspondente de 10.30.0.0/24 para 10.20.0.0/24 pelos seus próprios gateways MPLS. Redes, interfaces, gateways e serviços são valores de exemplo a adaptar à topologia real. A regra de firewall separada da filial permite LAN para a zona MPLS real, aqui MPLS_DMZ, apenas para estas redes e serviços; as regras da sede também devem permitir o fluxo previsto. Este design encaminhado mantém os endereços privados originais sem SNAT. Não é uma regra NAT universal para todas as instalações MPLS. Verificar ambos os sentidos e o IP de origem inalterado com tráfego real nas duas firewalls.

Configurar a rota SD-WAN

Definir critérios de correspondência

Para IPv6, selecionar hosts IP de destino específicos em vez de um destino genérico Any. Se uma rota genérica Any tiver de permanecer, criar acima dela uma rota para os hosts IP de destino específicos e o gateway previsto; manter também incoming interface, source e services restritos. Antes de alterar, registar a ordem instalada com system route_precedence show, a posição e as definições da rota, verificar acesso de gestão independente e planear a reposição destes valores. Uma rota mais específica não justifica repor a precedência global sem análise.

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

Criar um Application Object

O motor DPI pode reclassificar uma aplicação na mesma ligação, por exemplo ao passar de um site web para o respetivo chat. A nova decisão aplica-se às ligações seguintes; não garante o redirecionamento da ligação atual. Se não começar outra sessão dentro da TTL de 3600 segundos desde o início da sessão, os detalhes de sessão guardados são eliminados.

Os Application Objects podem incluir aplicações web, micro apps, Synchronized Security Applications descobertas nos endpoints, aplicações personalizadas e categorias de aplicações. Escolher o tipo conforme a deteção necessária e respeitar os limites de licença e DPI/proxy descritos acima; uma categoria inteira é mais abrangente do que uma única aplicação necessária.

Um Application Object agrupa apenas as aplicações que devem usar o mesmo caminho SD-WAN. Abra Applications > Application object, selecione Add, atribua um nome e restrinja os resultados através de Category, Risk, Characteristics, Technology, Classification ou da pesquisa por nome. Depois, selecione as aplicações realmente necessárias e guarde o objeto. A Sophos atualiza dinamicamente a lista de aplicações disponível através de atualizações IPS e do Synchronized Application Control; por isso, deve rever a seleção após alterações de patterns ou aplicações.

O filtro Technology distingue browser-based, client-server, network protocol, P2P e synchronized application control. Em Classification estão disponíveis new, sanctioned, unsanctioned e tolerated. Estes critérios facilitam a seleção, mas não provam que a rota seguinte funcione. Para o confirmar, é necessária primeiro a ligação de classificação e depois uma nova ligação de teste.

Para Microsoft 365, um único objeto coletivo é muitas vezes demasiado abrangente. Um objeto como Teams_VoIP pode conter apenas as aplicações Teams destinadas a comunicação em tempo real, enquanto OneDrive ou SharePoint utiliza outro caminho. Em seguida, selecione o objeto guardado no campo Application objects da rota SD-WAN.

Selecionar gateway ou SD-WAN profile

Primary/backup gateways são suficientes para um caminho preferencial e um fallback. Um SD-WAN profile separa duas decisões: Routing strategy escolhe o caminho através de First available gateway ou Load balancing; o Service Level Agreement (SLA) opcional acrescenta medições de qualidade a essa estratégia. Por isso, Best quality e Custom SLA não são duas estratégias de routing adicionais.

Configurar um SD-WAN profile em Routing > SD-WAN profiles > Add da seguinte forma:

Introduzir nome e descrição e selecionar First available gateway ou Load balancing em Routing strategy.
Atribuir entre dois e oito gateways e arrastá-los para a ordem pretendida. Gateway weights só aparece com load balancing; pesos diferentes podem representar capacidades distintas das ligações.
Para load balancing, selecionar Round-robin ou um Session persistence type adequado. A persistência pode basear-se em source IP, destination IP, source e destination ou numa ligação individual.
Ativar SLA apenas se latência, jitter ou perda de pacotes tiverem de influenciar a seleção. Best quality compara um único critério. Custom SLA verifica latência, jitter e perda de pacotes face aos limites configurados.
Ativar Health check, selecionar Ping ou TCP em Protocol e introduzir até dois Probe targets. Com TCP, indicar também uma porta em que o destino responda de forma fiável. O SFOS impõe Health Check quando SLA está ativo.
Ajustar Interval between checks, Response time-out, Deactivate gateway after, Activate gateway after e Sample size for SLA ao serviço. Estas definições têm funções diferentes: Interval between checks e Response time-out regulam as sondas; Deactivate gateway after conta tentativas sem sucesso e Activate gateway after respostas bem-sucedidas. Sample size for SLA define o número de amostras para o desempenho médio do gateway. Ajustar separadamente a deteção de falhas e a reativação; os cinco valores não formam um único temporizador de failover.
Guardar o profile, selecioná-lo na rota SD-WAN e verificar o caminho com tráfego real.

Os dois Probe Targets formam um único teste de disponibilidade: o SFOS considera o gateway ativo se pelo menos um responder. Se o primeiro falhar, muda para o segundo e continua a usá-lo enquanto responder. O regresso do primeiro, por si só, não provoca uma mudança imediata. Os destinos devem, por isso, estar atrás do gateway e representar o caminho relevante; um ping bem-sucedido não prova que DNS, TLS ou toda a aplicação funcionam.

Com Best quality, o failback só ocorre quando o gateway original é melhor em 10 ms de latência ou 5 ms de jitter; não existe margem equivalente para perda de pacotes. Em Routing > SD-WAN profiles, um profile ativo significa que pelo menos um gateway está disponível. Link status resume a configuração, Historical performance abre as medições e Object usage mostra as rotas que usam o profile. Verificar onde o profile é utilizado antes de o editar ou eliminar.

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.

Com Load balancing e Best quality, o tráfego só é distribuído se pelo menos dois gateways partilharem o melhor desempenho no critério selecionado; nem todos os gateways acessíveis são elegíveis. Com Custom SLA, a distribuição ocorre entre os gateways que cumprem os limites SLA configurados. Um caminho acessível que não cumpre o SLA não equivale a um gateway inacessível; isto não estabelece uma regra universal de fallback quando nenhum gateway cumpre o SLA.

Gateway weights define uma proporção de pedidos: no exemplo documentado, 3:1 significa três em cada quatro pedidos pelo primeiro gateway e um pelo segundo. Escolher os pesos conforme a capacidade e os recursos das ligações; não garantem a mesma proporção de bytes, um débito específico nem a agregação de ligações.

Em Custom SLA, Maximum latency e Maximum jitter são expressos em milissegundos e Maximum packet loss em pontos percentuais. Interval between checks define o intervalo entre sondas e Response time-out o tempo de resposta permitido. Deactivate gateway after conta tentativas de sondagem consecutivas sem sucesso; Activate gateway after conta respostas consecutivas bem-sucedidas. Sample size for SLA define o número de amostras de sondagem usadas para determinar o desempenho médio do gateway. Escolher estes valores para o serviço próprio, sem transformar um exemplo temporal isolado num valor predefinido universal.

Round-robin distribui os pedidos por ordem entre os gateways elegíveis. Com três gateways disponíveis, de igual peso e sem restrição SLA, o exemplo usa o primeiro, segundo, terceiro e novamente primeiro gateway. Session persistence type mantém as sessões relacionadas no mesmo gateway segundo a chave selecionada, por exemplo para serviços bancários ou carrinhos de compras. Um único fluxo de teste não mostra a distribuição de muitas sessões independentes.

Quando nenhum gateway cumpre o Custom SLA

O descarte por gateways inacessíveis não comprova um bloqueio rígido por SLA de caminhos que continuam acessíveis. Sem provas específicas da build, não garantir neste caso nem a continuação de Load balancing nem a utilização exclusiva de First available gateway.

Documentar build SFOS, profile, Routing strategy, ordem dos gateways, pesos, session persistence, limites SLA, probe targets e Route only through specified gateways.
Usar Link status, Historical performance e logs SD-WAN para distinguir caminhos acessíveis fora do SLA de caminhos realmente inacessíveis.
Testar apenas com um fluxo autorizado e isolado, numa janela de manutenção e com acesso de gestão independente. Não alterar profiles de produção partilhados para simular falhas nem eliminar gateways ou profiles. Criar novas ligações e comprovar gateway, IP SNAT e resultado da aplicação com Log Viewer e Packet Capture; avaliar separadamente as sessões existentes.
Repor os valores de teste alterados no estado inicial documentado e repetir as verificações de estado e o teste com tráfego real. Sem teste autorizado, a seleção permanece por resolver; um esclarecimento específico da build requer configuração, medições, datas e horas e logs juntamente com a build.

Um resultado para uma build e um profile não é uma garantia geral de failover.

Coordenar route precedence e NAT

A ordem predefinida documentada é Static → SD-WAN → VPN. Pode não corresponder ao estado de uma instalação existente: continuar a verificar system route_precedence show antes de decidir e não aplicar a predefinição automaticamente.

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.

DNAT para um servidor atrás de IPsec route-based

Uma publicação DNAT pública pode apontar para um servidor interno que não está ligado localmente, mas se encontra atrás de uma firewall remota através de IPsec route-based. Neste caso especial, DNAT e a rota SD-WAN têm de reconhecer o mesmo fluxo de entrada antes da tradução, e o caminho de retorno tem de passar novamente pela firewall que publica o serviço.

O procedimento fiável no SFOS 22 é composto por cinco partes relacionadas:

Em Hosts and services > IP host, criar um objeto IP exato para o servidor remoto.
Em Routing > Gateways, criar um gateway com o IP do gateway remoto e a interface XFRM correspondente. Como destino de monitorização, usar um host estável e acessível atrás desse gateway.
Fazer a regra DNAT corresponder à interface WAN pública e ao serviço oferecido externamente, e selecionar o servidor remoto como Translated destination. O exemplo da Sophos usa MASQ para que as respostas regressem à firewall que publica o serviço; no entanto, o servidor deixa de ver o IP original do cliente.
Na rota SD-WAN, inserir a mesma interface WAN pública em Destination networks e a porta externa em Services. Com PAT, trata-se expressamente da porta externa, não da porta de destino interna traduzida. Como primary gateway, selecionar o gateway da interface XFRM.
Verificar uma regra de firewall restrita para a publicação e testar o fluxo a partir de uma rede externa. NAT Rule ID, Firewall Rule ID, a rota SD-WAN, o gateway XFRM escolhido, os caminhos de ida e volta e o IP de origem visível no servidor devem corresponder ao design.

MASQ não é aqui uma opção cosmética. No exemplo documentado, resolve o caminho de retorno, mas oculta ao servidor de destino o IP real do cliente. Se o local remoto tiver um caminho de retorno comprovado para as redes de clientes originais e for necessário preservar o IP original, é necessário um design de routing planeado e testado separadamente. A publicação e proteção gerais são explicadas em Publicar um servidor por DNAT no Sophos Firewall.

Vários servidores remotos podem usar a mesma rota SD-WAN se forem acessíveis pelo mesmo gateway e puderem ser distinguidos inequivocamente pelo endereço WAN ou pela porta TCP externa. Se utilizarem gateways diferentes, devem ser configuradas rotas SD-WAN separadas. Se corresponder a porta, o objeto WAN ou o gateway errado, a rota não deve ser alargada para Any; primeiro deve confirmar-se o fluxo pré-DNAT com Log Viewer e Packet Capture.

Testar e aceitar a rota

Verificar a lista de rotas e o estado dos gateways

Em Routing > SD-WAN routes, é possível pesquisar por nome da rota, objeto ou valor do objeto; por exemplo, 443 encontra rotas que usam o serviço HTTPS. Arrastar e largar altera a ordem. Isto muda o tratamento do tráfego, porque o SFOS avalia de cima para baixo e para na primeira correspondência.

Em More options, é possível ativar ou desativar uma rota, editá-la ou cloná-la, repor o contador de dados ou eliminá-la. Antes de uma reposição, anotar o valor e a hora. Uma rota clonada é independente: verificar nome, critérios, posição, gateway e NAT antes de a guardar ou ativar e confirmar depois o estado On/Off real.

A descrição apresentada ao passar o cursor sobre o ícone na coluna Active mostra estados como In use, Available, Unavailable, In use, but SLA isn't met ou Available and SLA isn't met. Um gateway ou profile disponível não prova que esta rota foi aplicada nem que o caminho de retorno funciona.

Com seleção direta primary/backup, o ícone Active distingue três estados: pelo menos um gateway está acessível e a rota está ativa; a rota não está ativa e Route only through specified gateways está desativado; ou não está ativa e a opção está ativada. Neste último caso, o tráfego continua a ser descartado se os caminhos indicados estiverem inacessíveis, em vez de usar outros gateways. Ler em conjunto a descrição do ícone e a caixa de seleção, sem as equiparar a um estado SLA de um profile.

Teste padrão com tráfego real

Escolher um cliente de teste com IP conhecido e um destino inequívoco.
Ativar logging na regra de firewall correspondente.
Iniciar uma ligação real.
Em Log viewer, verificar source, destination, service, rule ID, NAT ID e gateway.
Verificar o traffic count da rota SD-WAN: OUT conta requests e IN replies apenas se source e destination corresponderem na direção respetiva.
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.
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.

Para logs de profile e rota na vista de firewall, selecionar o módulo Firewall em Log viewer, abrir a seleção expandida pelo botão de expansão junto à lista de módulos, selecionar os logs SD-WAN necessários e clicar em Apply. Isto complementa a vista do módulo SD-WAN separado.

Avaliar SD-WAN performance

O eixo x dos gráficos de qualidade mostra o tempo; o eixo y mostra latência e jitter em milissegundos e perda de pacotes em pontos percentuais. Assigned weights for load balancing abre os pesos atribuídos aos gateways. As medições e os pesos não constituem a aceitação da aplicação.

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 latência, 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 rota a utilizar o profile selecionado ou que não passa tráfego por uma rota desse tipo. A mensagem não comprova, por isso, uma falha de medição. Primeiro gera-se um fluxo controlado pela rota 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

Antes de uma alteração, anotar a posição e o estado On/Off atuais da rota, os primary/backup gateways ou o profile utilizado, a ordem dos gateways no profile, os valores de SLA e Health Check e a tradução NAT esperada. O rollback consiste em restaurar exatamente esses valores e voltar a verificar estado, logs e tráfego real.

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.

Alterar o rerouting de forma consciente

Estas definições alteram o tráfego; não são requisitos do teste de referência. Alterar apenas numa janela de manutenção com acesso de gestão independente verificado e rollback documentado: guardar primeiro os dois estados de rerouting mostrados acima e verificar que ambos os caminhos usam o mesmo IP de origem traduzido para SNAT. Na Device Console estão disponíveis as seguintes alternativas; executar apenas o comando necessário à alteração pretendida, não todos em sequência:

Ativar sem SNAT: set routing reroute-connection enable; desativar: set routing reroute-connection disable.
Ativar para SNAT: set routing reroute-snat-connection enable; desativar: set routing reroute-snat-connection disable.

Depois verificar com show routing reroute-connection e show routing reroute-snat-connection e testar separadamente sessões, IP de origem e ambos os sentidos do tráfego. Para reverter, restaurar cada definição alterada para o estado enable/disable registado e repetir as verificações de estado e tráfego real. Ativar rerouting SNAT não elimina as restrições MASQ/IP.

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 os pacotes de resposta e o tráfego gerado pelo sistema, aplicam-se definições de configuração e regras de correspondência próprias. Estes casos são explicados em Verificar SD-WAN routing para reply packets e system traffic no Sophos Firewall.

Web Admin e SSH ficam inacessíveis após uma nova rota

Um cenário documentado combina quatro definições: SD-WAN precede Static, uma nova rota para uma rede de origem interna específica tem destination Any, o routing SD-WAN para tráfego gerado pelo sistema está ativado e o routing SD-WAN para reply packets também. O acesso de gestão a partir da rede interna abrangida pode então perder-se, permanecendo possível a partir de outras sub-redes. Não são condições necessárias para todas as falhas de gestão.

Através de um acesso alternativo previamente verificado, verificar origem, destino e precedência da rota, bem como estes valores apenas de leitura na Device Console:

show routing sd-wan-policy-route system-generate-traffic
show routing sd-wan-policy-route reply-packet

Primeiro verificar que a gestão a partir de uma sub-rede não abrangida é realmente permitida e acessível. Depois limitar o destino de forma deliberada ou restaurar uma das definições previamente alteradas para o valor original documentado. Não efetuar uma reposição global sem análise: guardar antes posição, definições e precedência, planear o rollback e voltar a verificar Web Admin, SSH e o tráfego afetado. Sem acesso alternativo seguro, não continuar a alteração remotamente.

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 imediatamente após o upgrade para o SFOS 22.0 GA, deve verificar-se primeiro a build instalada. O SFOS 22.0 MR1 Build 490 corrige NC-173667, que causava a desconexão aleatória de uma rota SD-WAN, e NC-177603, devido ao qual o áudio VoIP através de uma VPN route-based só funcionava num sentido após o upgrade para o 22.0 GA. Se já estiver instalada a MR1 ou uma build posterior, não se deve atribuir a falha apenas à versão do firmware; deve repetir-se o teste com tráfego real descrito acima e verificar a rota, as sessões, o NAT e ambos os sentidos do tráfego.

API XML: esclarecer os limites dos objetos antes de automatizar

A documentação da API XML para SFOS 22.0 e 23.0 descreve objetos nomeados separados. A configuração pela interface descrita acima continua a ser o procedimento prático; contudo, não permite deduzir um contrato XML inequívoco. As contradições seguintes têm de ser esclarecidas antes de construir um pedido. Para automatizar, é necessário obter da Sophos um esclarecimento dos campos afetados específico para a versão; aqui não se propõe qualquer correspondência numérica nem se fornece um pedido XML executável.

HealthCheckProfile nomeado: ciclo de vida e contadores de sondas

HealthCheckProfile é um objeto de Health Check independente, não o SDWANProfile nem a opção de Health Check integrada do gateway. Na criação e atualização, o campo escalar obrigatório do tipo string Name identifica o profile de Health Check; ambas as tabelas de campos indicam um máximo de 125 caracteres. A tabela da versão 22.0 proíbe também vírgulas e permite expressamente caracteres UTF-8, enquanto estas duas indicações não constam da tabela da versão 23.0. Esta ausência não comprova uma alteração da validação do nome.

ProbeTargets é descrito como um array de objetos monitorDetails, mas o exemplo contém elementos ProbeTarget. monitormethod indica TCP ou PING; monitorip indica os tipos de dados IPADDRESS, IPADDRESS6 e DOMAINNAMELOOKUP. Para operator, constam os literais & e |, com o valor predefinido |. Isto não permite deduzir uma estrutura XML diferente nem uma equivalência com o comportamento dos dois Probe Targets na interface descrito acima. Também IPFamily continua a ser contraditório: ambas as tabelas indicam IPv4 e IPv6, com o valor predefinido IPv4, mas simultaneamente um máximo de 1 carácter.

As duas linhas dos contadores parecem estar trocadas em relação aos respetivos nomes: ProbesResponseFailure descreve literalmente respostas consecutivas para ativar o objeto, com o valor predefinido 1; ProbeResponseSuccess descreve sondas consecutivas sem resposta antes de o desativar, com o valor predefinido 3. Ambas as tabelas indicam, para cada contador, o intervalo de 1 a 10. Esta associação documental não é corrigida implicitamente e não confirma o comportamento em execução. Em particular, as explicações seguras da interface sobre Deactivate gateway after e Activate gateway after não são automaticamente transpostas para estas tags da API.

A operação de eliminação separada também identifica o profile de Health Check através de Name, não uma rota nem um SD-WAN profile. Antes de uma eliminação planeada, verificam-se os SD-WAN profiles que o referenciam e documenta-se a respetiva associação de Health Check existente. As fontes não comprovam um procedimento de eliminação em cascata seguro nem o comportamento ao eliminar um objeto de Health Check que ainda esteja referenciado. Isto não equivale à eliminação de um SD-WAN profile descrita acima; essa eliminação também não constitui um teste de falha.

HealthCheckProfileStatus: estado administrativo do objeto de Health Check

HealthCheckProfileStatus ativa ou desativa administrativamente o profile de Health Check nomeado. O seletor é o campo escalar obrigatório do tipo string Name; o marcador de posição do exemplo HealthCheckProfileStatusName não altera a identidade deste campo. Em ambas as versões, o exemplo apresenta ON/OFF para Status, mas a linha do campo obrigatório indica INTEGER sem correspondência numérica. Isto não comprova uma representação numérica para ativar ou desativar. Esta administração não corresponde à disponibilidade medida do gateway, ao estado ativo de um SD-WAN profile nem à ativação ou desativação de uma rota. Uma mensagem de sucesso documentada, por si só, não comprova que a alteração de estado tenha efetivamente ocorrido; seria necessário verificar o estado administrativo deste objeto nomeado específico, separadamente dos indicadores de disponibilidade.

SDWANPolicyRouteStatus: verificar a rota e o estado corretos

SDWANPolicyRouteStatus utiliza SDWANPolicyRouteName como seletor escalar obrigatório do tipo string, não o Name de um profile de Health Check. Os exemplos de ambas as versões apresentam novamente ON/OFF para Status, enquanto a linha do campo obrigatório indica INTEGER e não fornece qualquer correspondência numérica. O código de resultado documentado 200 não é uma confirmação independente de que a rota pretendida tenha alterado o seu estado administrativo. Para isso, seria necessário verificar o estado On/Off real dessa rota. A descrição apresentada ao passar o cursor sobre Active, a acessibilidade do gateway e a decisão de descarte ou fallback determinada por Route only through specified gateways respondem a outras questões e não resolvem a contradição do contrato XML relativo ao estado.

SDWANProfile: família, estratégia e referência de Health Check separada

Em SDWANProfile, Name designa o próprio SD-WAN profile, com um máximo de 60 caracteres. Já o campo escalar obrigatório do tipo string HealthCheckProfileName é a referência ao profile de Health Check separado, com um máximo de 85 caracteres. Não se trata da mesma identidade nem do mesmo comprimento de nome documentado para o respetivo Name, de 125 caracteres. Por isso, os limites do objeto e dos contadores de HealthCheckProfile também se aplicam à preparação desta referência; as definições de Health Check integradas não substituem a referência nomeada obrigatória.

Ambos os exemplos de profile e as descrições dos campos indicam IPv4/IPv6 para IPFamily, mas a linha de validação permite apenas IPv4 e indica simultaneamente um máximo de 1 carácter. As rotas IPv6 na interface não comprovam, por isso, suporte de IPv6 neste contrato XML de profile. Para SLAStrategy, o exemplo e a descrição apresentam BestQuality, mas a lista de valores permitidos apresenta BestQualityv; CustomSLA consta de ambos. Para LBMethod, o exemplo indica WRR/SrcSticky/DestSticky/SrcDestSticky/ConnectionSticky, enquanto a tabela indica INTEGER no intervalo de 0 a 5, sem correspondência com estes valores de texto. Para IsLatency, o valor predefinido 1 contrasta com os literais permitidos OFF e ON. Nenhuma destas diferenças é resolvida por uma suposta correção ortográfica, uma representação numérica ou uma correspondência booleana deduzida. As estratégias e os procedimentos de verificação da interface descritos acima continuam a ser úteis, mas não comprovam a existência de um pedido de profile executável.

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