Configurar e testar uma rota estática na Sophos Firewall

Uma rota estática indica à Sophos Firewall por que next hop fixo ou interface de túnel deve alcançar um determinado destino. É adequada quando o caminho está definido e não é necessário selecionar com base em source, service, aplicação ou qualidade da ligação.

Resposta curta

Uma rota IPv4 é criada aqui:

Routing > Static routes > IPv4 unicast route > Add

Para uma rede de destino 10.20.0.0/24, acessível através do router 192.0.2.2 em Port4, introduza:

Destination IP / Netmask: 10.20.0.0/24
Gateway IP: 192.0.2.2
Interface: Port4
Administrative distance: 1
Metric: 10
Description: Branch_10.20_via_Core

A rede de destino, o gateway e a interface devem corresponder ao ambiente real. Só reutilize Administrative Distance e Metric depois de verificar as rotas existentes para o mesmo destino; 1 e 10 são apenas valores de exemplo.

Em seguida, verifique o destino 10.20.0.10 em Diagnostics > Tools > Route lookup. Se o resultado mostrar Port4, a decisão de routing está correta. A alteração só fica totalmente validada quando uma ligação real do cliente funciona e a resposta regressa.

Para que o tráfego funcione, também são necessárias uma regra de firewall adequada e uma rota de retorno no equipamento remoto. Uma rota estática não permite tráfego nem executa NAT automaticamente.

Compreender o exemplo

O exemplo utiliza a seguinte estrutura:

A rede de clientes atrás da Sophos Firewall é 10.10.0.0/24.
O cliente de teste nesta rede é 10.10.0.10.
A Port4 da firewall tem o IP de trânsito 192.0.2.1/30.
O router seguinte tem o IP 192.0.2.2 nesta rede.
Atrás deste router encontra-se a rede de destino 10.20.0.0/24.
O sistema de teste é 10.20.0.10.

O Destination é sempre o destino remoto, não o router seguinte. Gateway IP é o next hop diretamente acessível que encaminha o pacote. Interface é a porta ou interface de túnel através da qual esse next hop é alcançado.

O destino pode ser uma rede ou um único host. Se apenas o sistema de teste tiver de utilizar este caminho, escolha, por exemplo, 10.20.0.10/32 para IPv4 ou 2001:db8:20::10/128 para IPv6, em vez de uma rede inteira. Um prefixo mais amplo inclui outros endereços de destino e só deve ser escolhido se também forem acessíveis através deste next hop. A autorização da firewall continua a ser independente.

O endereço é introduzido diretamente em Gateway IP; não é necessário um objeto de gateway em Routing > Gateways. Para adaptar o exemplo ao seu ambiente, substitua em conjunto a rede de destino, o gateway e a interface. Se for utilizado apenas um endereço do exemplo, a rota pode ser guardada, mas apontar para a rede errada ou para um router inacessível. O IP do gateway tem de pertencer à rede da interface selecionada.

Se, pelo contrário, o caminho precisar de um Health Check próprio ou tiver de poder ser selecionado numa SD-WAN Route, deve seguir-se o procedimento específico para Custom Gateways no Sophos Firewall.

Os fundamentos sobre porta, zona e IP da interface são explicados em Configurar zonas e interfaces na Sophos Firewall.

Quando utilizar uma rota estática

Este artigo aborda redes de destino Unicast. Se um emissor tiver de alcançar um grupo Multicast através de várias interfaces, deve seguir o procedimento separado Configurar Multicast com uma rota Multicast estática.

O multicast envia um único fluxo para um grupo, em vez de cópias separadas para cada destinatário, por exemplo para videoconferências, formação ou distribuição de software. Os destinatários têm de aderir ao grupo; emissores, destinatários e routers envolvidos têm de suportar multicast. Os endereços de grupo IPv4 vão de 224.0.0.0 a 239.255.255.255, enquanto o endereço de origem continua a ser unicast. Este é o intervalo geral, não uma autorização para utilizar todos os destinos numa rota multicast estática. Em Routing > Static routes, Enable multicast forwarding ativa o encaminhamento. Manage multicast route permite adicionar, editar, eliminar e filtrar por IP de origem, IP multicast, Source Interface ou Destination Interface. O procedimento multicast ligado explica os requisitos, o intervalo permitido, o teste seguro e o rollback.

Uma rota estática é útil quando uma rede está permanentemente acessível através do mesmo next hop, por exemplo:

uma rede de filial atrás de um Core Router interno
uma rede de servidores atrás de um switch Layer 3
uma rede atrás de um túnel RED
uma rede remota através da interface XFRM de um túnel IPsec route-based

Se a firewall também tiver de decidir com base em source, service ou aplicação, ou alternar os caminhos de acordo com latência, jitter e perda de pacotes, uma rota SD-WAN é geralmente mais adequada. Em domínios de routing pequenos ou existentes, o RIPv2 pode trocar automaticamente redes simples. Em redes maiores e sujeitas a alterações frequentes, OSPF ou BGP reduzem o trabalho de manutenção manual.

Configurar uma rota IPv4

Antes da alteração, documente a rede de destino, o next hop, a interface de saída, a zona esperada, o caminho de retorno e um host de teste acessível. Em seguida:

Abra Routing > Static routes.
Em IPv4 unicast route, clique em Add.
Em Destination IP / Netmask, introduza 10.20.0.0/24.
Em Gateway IP, introduza o router seguinte 192.0.2.2.
Selecione Port4 como Interface.
Defina Administrative distance como 1.
Em Metric, introduza 10.
Adicione uma Description clara, como Branch_10.20_via_Core.
Guarde com Save.

Para esta rota, a Sophos Firewall considera primeiro a interface selecionada e depois o gateway. Se um dos dois campos estiver incorreto, o next hop previsto não será alcançado. Na lista IPv4, pode filtrar por endereço IP, Gateway IP, Interface ou Description e editar, clonar, eliminar, ativar ou desativar rotas. A lista IPv6 permite filtrar por endereço IP, Gateway IP ou Interface e adicionar, editar ou eliminar rotas.

Administrative Distance e Metric

A Administrative Distance avalia fontes de routing concorrentes. Um valor inferior tem prioridade: uma rota com 1 é preferida a uma rota com 5.

Se várias rotas estáticas para o mesmo destino tiverem a mesma Administrative Distance, a Metric determina a escolha. Também neste caso é preferido o valor inferior.

A Route Precedence global entre Static, SD-WAN e VPN atua a um nível diferente de Administrative Distance e Metric. Não deve ser alterada precipitadamente por causa de uma única rota nova.

Os valores de exemplo 1 e 10 são valores iniciais simples para uma única rota, não uma recomendação geral do produto. Antes de os utilizar, compare as rotas existentes para o mesmo destino. Para Primary/Backup ou ECMP, a Administrative Distance e a Metric são escolhidas deliberadamente de acordo com a prioridade pretendida.

Duas rotas com Administrative Distance diferente podem descrever um caminho preferencial e um caminho secundário. No entanto, Administrative Distance e Metric não monitorizam o next hop por si próprias. Para verificar a disponibilidade, utilize um gateway monitorizado numa rota SD-WAN. Para selecionar o caminho por latência, jitter ou perda de pacotes, a rota também necessita de um SD-WAN Profile com Best quality ou Custom SLA.

Tornar o IPsec route-based redundante com duas ligações à Internet apresenta um exemplo completo com dois operadores e dois túneis XFRM Any-to-Any. Gateways, rotas simétricas, Route Precedence, Failover e Failback são validados em conjunto.

Para IPv4 ECMP, crie várias rotas para o mesmo destino com Administrative Distance e Metric iguais, mas next hops diferentes. As ligações podem assim ser distribuídas entre next hops de custo igual; não é criado um caminho Primary/Backup baseado na qualidade.

Utilizar Blackhole de forma consciente

Com Blackhole, a firewall elimina o tráfego para o destino especificado sem notificar a source. Isto pode ser útil para redes deliberadamente bloqueadas ou agregadas, mas não substitui um next hop normal.

Se as rotas estáticas forem redistribuídas através de RIP, OSPF ou BGP, as rotas Blackhole devem ser filtradas especificamente. Caso contrário, a firewall também poderá anunciar esta rota de bloqueio a outros routers.

IPv6 e casos especiais de túneis

Em IPv6 unicast route, introduza o endereço de destino com prefix, Gateway IP, Interface e Metric. A Sophos não documenta para o formulário IPv6 Administrative Distance, opção Blackhole, Description, Clone ou função de ativação e desativação. Por isso, as definições IPv4 não devem ser aplicadas a IPv6 sem verificação.

Para uma rede IPv6 com routing normal, siga estes passos:

Em Routing > Static routes > IPv6 unicast route, clique em Add.
Introduza uma rede de destino, por exemplo 2001:db8:20::/64.
Introduza 2001:db8:4::2 em Gateway IP e selecione Port4 em Interface.
Escolha uma Metric como 10 após comparar as rotas existentes e guarde com Save.

O exemplo pressupõe 2001:db8:4::1/64 em Port4 e um router diretamente acessível em 2001:db8:4::2. Todos os endereços IPv6 são valores de documentação; substitua-os em conjunto pelos do seu plano de endereçamento. Antes da alteração, registe os valores anteriores das rotas e garanta acesso de gestão independente. Depois, verifique 2001:db8:20::10 com Route lookup, uma ligação real de cliente IPv6 e Packet capture com host 2001:db8:20::10; o tráfego de saída e as respostas têm de seguir o caminho previsto. São também necessárias uma regra de firewall IPv6 e uma rota de retorno à rede de clientes. A exceção RED/ARP abaixo não demonstra que o mesmo mecanismo se aplique a IPv6; confirme qualquer caso específico de RED IPv6 para o build instalado antes da alteração.

Num túnel IPsec route-based com subnets Any-to-Any, a rota pode apontar diretamente para a interface XFRM, sem ser necessário um gateway separado. Se o túnel utilizar Traffic Selectors específicos, o SFOS cria automaticamente a rota; nesse caso, não configure endereços IP próprios nem rotas adicionais na interface XFRM. Uma rota XFRM também não corresponde ao caso especial de CLI ipsec_route, que depende da versão; a distinção é explicada em Criar uma rota IPsec na Sophos Firewall.

Para uma rede atrás da interface peer de um túnel RED Site-to-Site entre Sophos Firewalls, aplica-se outra exceção: introduza como gateway o IP da interface RED peer, mas não selecione uma interface. Desta forma, a firewall pode determinar através de ARP qual é a interface acessível. Configurar Site-to-Site RED entre duas Sophos Firewall explica o design completo de servidor e cliente.

Regra de firewall, NAT e caminho de retorno

O routing determina o caminho. A regra de firewall decide se o pacote pode passar e o NAT altera os seus endereços quando necessário. Estas três tarefas são configuradas separadamente.

Para o exemplo, é necessária uma regra da rede de clientes 10.10.0.0/24 para a rede de destino 10.20.0.0/24. A Destination Zone corresponde à zona de Port4. Limite a regra aos serviços realmente necessários e ative o logging durante o teste.

Numa rede de localização com routing normal, geralmente não se pretende SNAT, porque o equipamento remoto deve ver o IP real do cliente. O router 192.0.2.2 necessita então desta rota de retorno:

Rede de destino: 10.10.0.0/24
Next Hop: 192.0.2.1

Se não for possível configurar uma rota de retorno no equipamento remoto, o SNAT pode ajudar tecnicamente. No entanto, oculta o IP original do cliente e deve continuar a ser uma decisão consciente de arquitetura. As relações são explicadas em Compreender o NAT na Sophos Firewall.

Rotas estáticas através da API XML: campos e limites de edição

Ao automatizar rotas estáticas, é necessário distinguir os campos XML em UnicastRoute das designações na interface. As tabelas de parâmetros da API para SFOS 22.0 e 23.0 documentam o seguinte:

Distance designa a Metric, não a Administrative Distance: opcional, valor predefinido 0, intervalo 0–255.
AdministrativeDistance designa a Administrative Distance: opcional, valor predefinido 1, intervalo 1–255.

Estes valores predefinidos da API não são uma recomendação para a rota apresentada acima nem demonstram que os campos omitidos permanecem inalterados durante uma atualização. A prioridade pretendida continua a ter de ser comparada com as rotas existentes.

O exemplo XML também contém OldConfiguration com os campos anteriores de destino, gateway, interface e prioridade. No entanto, a tabela de parâmetros não descreve este bloco. Por isso, o exemplo não demonstra quais os campos que identificam a rota a editar, quais os valores anteriores obrigatórios nem se as alterações concorrentes são detetadas ou comparadas de forma atómica. A automatização não deve basear-se neste exemplo para garantir a correspondência nas atualizações ou o controlo de concorrência.

Também nos campos de endereço existem inconsistências entre o exemplo e a tabela:

IPFamily: o exemplo apresenta IPv4/IPv6, enquanto a tabela indica o tipo de dados INTEGER e o valor predefinido IPv4.
DestinationIP: a descrição refere endereços IPv4/IPv6, mas o tipo de dados é IPADDRESS6.
Netmask: o exemplo apresenta 0.0.0.0, enquanto a tabela descreve um prefixo como INTEGER no intervalo 0–128.

Não é possível deduzir daí um pedido IPv4/IPv6 universal e executável. Antes de editar através da API em produção, esclareça e verifique num ambiente de teste o esquema do pedido e a correspondência inequívoca com a rota existente para o build instalado. Registe previamente os valores anteriores e garanta acesso de gestão independente. Depois, verifique os valores de rota guardados, Route Lookup e uma ligação real de cliente, incluindo o caminho de retorno; o rollback descrito abaixo continua a ser necessário. Enquanto o esquema ou a correspondência não forem claros, efetue a alteração pelo procedimento na interface descrito acima, em vez de utilizar um pedido XML baseado em suposições.

A eliminação tem limites de documentação próprios. As tabelas de Delete Unicast Route para SFOS 22.0 e 23.0 assinalam DestinationIP e Netmask como campos obrigatórios. No entanto, isso não comprova que constituam um seletor completo e inequívoco da rota a eliminar. As dez células de valores predefinidos estão em branco; daí não se pode deduzir um valor 0, «inalterado» ou null. Para IPFamily, é indicado apenas o tipo de dados INTEGER, sem correspondência entre os valores permitidos e IPv4 ou IPv6. Não existe um exemplo de pedido Delete.

Por isso, os valores predefinidos de Add/Update e os pressupostos relativos a OldConfiguration descritos acima não devem ser aplicados a Delete. Enquanto o esquema do pedido e a identificação inequívoca da rota de destino não estiverem esclarecidos para o build instalado, deve utilizar-se o procedimento na interface e o rollback descrito abaixo para remover a rota, e não um pedido de eliminação XML baseado em suposições. Antes, devem registar-se os valores anteriores das rotas e garantir-se acesso de gestão independente; depois, devem verificar-se os valores das rotas, Route Lookup e uma ligação real de cliente, incluindo o caminho de retorno.

Verificar a rota

Uma rota guardada só é considerada validada quando um cliente real alcança o equipamento remoto e o caminho de retorno funciona.

As verificações CLI abaixo são executadas em 4. Device Console, não na Advanced Shell, e apenas consultam o estado atual. Antes de as executar, confirme a sintaxe completa no build instalado com Tab ou ?. Não execute comandos incompletos: podem fazer com que o serviço access_server deixe de responder.

Em Diagnostics > Tools > Route lookup, introduza 10.20.0.10. O resultado deve mostrar Port4.
Na Device Console, verifique as rotas IPv4 ou IPv6 configuradas e, em caso de concorrência com SD-WAN ou VPN, a Route Precedence:
```
show static-route
show static-route6
system route_precedence show
```
A partir do cliente 10.10.0.10, inicie uma ligação real a 10.20.0.10, por exemplo Ping ou TCP 443, de acordo com a regra de firewall.
No Log viewer, verifique source, destination, service, Firewall Rule ID e uma possível NAT Rule ID.
Em Diagnostics > Packet capture, utilize host 10.20.0.10 para verificar se os pedidos saem por Port4 e se as respostas regressam.

Se Route Lookup mostrar o caminho correto, mas o tráfego não passar, a causa encontra-se geralmente na regra de firewall, no NAT, na rota de retorno ou no sistema de destino. O teste completo do fluxo de pacotes é apresentado em Testar uma regra da Sophos Firewall com Log Viewer e Packet Capture.

Para problemas de routing mais complexos, as últimas entradas do log Unicast e do log do kernel na Device Console são úteis:

show logs staticd.log lines 50
show logs zebra.log lines 50

staticd.log refere-se a rotas Unicast estáticas; zebra.log mostra a instalação de rotas Unicast estáticas IPv4 no kernel. Serviços e ficheiros de log da Sophos Firewall associa outros ficheiros de log aos serviços responsáveis.

Após o reinício de uma interface ou túnel, uma rota que especifique apenas o gateway pode inicialmente não aparecer na tabela de routing. Surge assim que o tráfego adequado corresponde ao destino e ao gateway e a firewall seleciona a interface. A ausência da entrada imediatamente após o reinício ainda não demonstra uma falha.

Identificar erros e efetuar rollback

Route Lookup mostra a interface errada

Verifique o endereço de destino e o prefix; um erro de introdução pode corresponder a outra rede.
O gateway deve estar diretamente acessível através da interface selecionada.
Compare as rotas estáticas concorrentes, bem como Administrative Distance e Metric.
Com SD-WAN ou VPN, verifique a ordem atual com system route_precedence show. A alteração global é explicada em Alterar Route Precedence com segurança.

O pedido sai, mas não chega nenhuma resposta

Verifique a rota de retorno no router seguinte e no sistema de destino.
Verifique a regra de firewall para a direção inicial e as regras NAT existentes. Só é necessária uma regra na direção oposta se o equipamento remoto iniciar novas ligações.
Utilize Packet Capture para confirmar se a resposta regressa a Port4.
Verifique a firewall local e o default gateway do sistema de destino.

Rollback seguro

Uma nova rota IPv4 é primeiro desativada em vez de eliminada. Em seguida, volte a verificar Route Lookup, uma nova ligação de cliente e o caminho anterior. Só depois de confirmar o estado inicial deve remover, se necessário, a rota e as regras ou objetos NAT criados exclusivamente para esta alteração.

Para IPv6, a Sophos não documenta uma função de ativação e desativação. Por isso, registe previamente os valores anteriores e edite ou remova a nova rota durante um rollback. Num cluster HA, repita o teste end-to-end após um failover no novo Primary.