Configurar e verificar OSPF na Sophos Firewall

O OSPF troca automaticamente rotas IPv4 entre routers. Isto é útil quando existem várias localizações, caminhos redundantes ou redes que mudam com frequência e que já são difíceis de manter com rotas estáticas.

No exemplo seguinte, duas Sophos Firewalls formam uma vizinhança OSPF através de uma rede de trânsito dedicada. No final, o Neighbor encontra-se em Full, a Firewall A conhece a LAN atrás da Firewall B e vice-versa. Para IPv6, o OSPFv3 é configurado separadamente.

⚠️ O OSPF só deve funcionar em interfaces de trânsito ou VPN destinadas a esse fim e consideradas fidedignas. Não permitir Dynamic Routing de forma geral nas zonas LAN e WAN, nem ativar Redistribute connected antes de estar claro que redes diretamente ligadas serão anunciadas dessa forma.

OSPF em sete passos

Uma ligação OSPFv2 simples requer os seguintes passos:

Atribuir endereços às interfaces de trânsito e verificar a conectividade IP direta.
Em Administration > Device access, permitir Dynamic Routing para uma zona de trânsito própria ou através de uma Local Service ACL Exception estritamente limitada.
Em Routing > OSPF, introduzir um Router ID único em cada firewall.
Criar a Area 0.0.0.0 como Normal.
Em Networks, atribuir a rede de trânsito local à Area 0.0.0.0.
Anunciar apenas as rotas LAN realmente necessárias.
Em Routing > Information > OSPF, verificar o estado Full do Neighbor e a rota aprendida.

Uma Network OSPF não é a rede de destino remota. A entrada ativa o OSPF nas interfaces locais cujo endereço IP pertence a essa rede. A LAN remota só aparece quando o outro lado a anuncia através de OSPF.

O que o OSPF decide na firewall

O OSPF é um protocolo de routing interno do tipo link-state. Os routers vizinhos trocam informações sobre as redes e os caminhos alcançáveis, constroem uma Link-State Database e calculam o melhor caminho. Um Cost mais baixo é preferido a um mais alto.

Assim, o OSPF resolve uma tarefa diferente das regras de firewall e do SD-WAN:

O OSPF aprende e distribui redes de destino dentro do próprio domínio de routing.
Uma regra de firewall continua a decidir se o tráfego útil pode passar entre as zonas e redes envolvidas.
O NAT altera endereços quando necessário, mas não faz parte do OSPF.
Uma SD-WAN Route pode ainda decidir com base na origem, no serviço, na aplicação ou na qualidade da ligação.

A Sophos Firewall classifica as rotas aprendidas dinamicamente na categoria static da Route Precedence global. Se uma rota OSPF competir com uma rota SD-WAN ou VPN, a Route Precedence também tem de corresponder ao fluxo de pacotes pretendido. Dentro do OSPF, pelo contrário, é o Cost que decide.

O OSPFv2 processa IPv4. O OSPFv3 desempenha a mesma função para IPv6, mas é configurado separadamente na Sophos Firewall.

Planear a topologia de exemplo

Os valores do exemplo representam duas localizações:

Firewall A: Router ID 192.0.2.10, IP de trânsito 198.51.100.1/30, LAN local 10.10.10.0/24
Firewall B: Router ID 192.0.2.20, IP de trânsito 198.51.100.2/30, LAN local 10.20.20.0/24
Rede de trânsito: 198.51.100.0/30
OSPF Area: 0.0.0.0

Os endereços 192.0.2.0/24 e 198.51.100.0/24 são redes de documentação. Devem ser substituídos pelos valores reais do ambiente.

O Router ID tem o aspeto de um endereço IPv4, mas não precisa de estar atribuído a uma interface. O importante é que seja único dentro do domínio OSPF e permaneça estável de forma duradoura. 0.0.0.0 não é permitido. Sem um valor próprio, o SFOS utiliza o endereço de interface mais alto; um Router ID escolhido de forma consciente evita que a identidade mude inesperadamente após uma alteração de interface.

Para esta configuração simples, a Backbone Area 0.0.0.0 é suficiente. Várias Areas só se justificam quando se pretende estruturar e agregar deliberadamente um domínio de routing maior. Cada Area adicional necessita de uma ligação à Backbone Area.

Preparar o OSPF em segurança

Antes da configuração do OSPF, devem estar reunidas as seguintes condições:

A firewall está a funcionar em Gateway Mode. O OSPF não está disponível em Transparent Mode.
Os dois IPs de trânsito pertencem à mesma rede e conseguem comunicar diretamente, por exemplo através de Ping.
A interface, a máscara de sub-rede, o MTU e a zona estão documentados.
O Router ID, a Area, a Authentication, o Hello interval e o Dead interval estão alinhados em ambos os lados.
Estão disponíveis um backup da configuração e um acesso de gestão independente.
Foram planeadas regras de firewall e caminhos de retorno adequados para as duas LANs.

Uma VLAN de trânsito própria e uma zona de trânsito dedicada facilitam a proteção. Os fundamentos são explicados em Configurar zonas e interfaces da Sophos Firewall.

Permitir Dynamic Routing de forma seletiva

Em Administration > Device access, a opção Dynamic Routing está desativada por predefinição para todas as zonas. No exemplo, o serviço só é ativado na zona de trânsito dedicada à qual está associada a rede 198.51.100.0/30.

A caixa de seleção na matriz Device Access aplica-se a toda a zona e não apenas a uma interface. Se a interface de trânsito partilhar a zona com outras redes, uma Local Service ACL Exception deve limitar o serviço à rede de trânsito e aos peers previstos.

Esta autorização diz respeito aos pacotes OSPF destinados à própria firewall. Não é necessária uma regra de firewall normal para esse fim. O tráfego de dados entre 10.10.10.0/24 e 10.20.20.0/24 continua, no entanto, a precisar de regras de firewall IPv4 adequadas. A distinção entre serviços locais e tráfego encaminhado é explicada em Proteger o Device Access na Sophos Firewall.

Configurar OSPFv2 no WebAdmin

Os passos seguintes são executados nas duas firewalls. Apenas o Router ID, o IP de trânsito e a LAN local são diferentes.

1. Definir as configurações globais

Em Routing > OSPF, são definidos os valores globais:

Router ID: na Firewall A 192.0.2.10, na Firewall B 192.0.2.20
Default metric: manter em 20, salvo se existir uma definição deliberada para as rotas redistribuídas
ABR type: para uma nova configuração padrão, Standard
Auto-cost reference-bandwidth: manter o valor padrão 100000 Mbps enquanto o planeamento de custos não exigir outro valor de referência comum
Default-information originate: Never, enquanto a firewall não tiver de distribuir explicitamente uma Default Route a todos os vizinhos OSPF
Redistribute connected, static, RIP e BGP: manter inicialmente desativados

Em seguida, aplicar a configuração global com Apply.

A Default Metric afeta as rotas que são importadas de outras origens para o OSPF. O Interface Cost determina, pelo contrário, a escolha do caminho dentro da topologia OSPF. O Cost mais baixo ganha.

Default-information originate: Always não deve ser utilizado como um interruptor rápido de failover da Internet. Dessa forma, a firewall anunciaria uma Default Route mesmo que não tivesse uma. Regular só a anuncia quando existe uma Default Route na tabela de routing.

2. Criar a Backbone Area

Na secção Areas, clicar em Add e definir os seguintes valores:

Area: 0.0.0.0
Type: Normal

Na Area, selecionar Text ou MD5 como Authentication Type. Se o peer suportar MD5, esta opção é preferível ao texto simples. O respetivo Key ID e a chave são introduzidos mais tarde na interface de trânsito. O MD5 autentica os pacotes OSPF, mas não encripta as informações de routing trocadas.

Depois, guardar a Area com Save.

3. Adicionar a rede de trânsito

Na secção Networks, clicar em Add:

IPv4/Netmask: 198.51.100.0/30
Area: 0.0.0.0

Na Firewall A, o endereço 198.51.100.1 corresponde a esta Network; na Firewall B, corresponde o endereço 198.51.100.2. Desta forma, o OSPF funciona nas respetivas interfaces de trânsito e as duas firewalls podem formar uma vizinhança.

Guardar a entrada Network com Save.

A LAN local não é simplesmente introduzida como um suposto destino remoto. Uma entrada Network adicional pode anunciá-la mesmo sem um vizinho, mas também ativa o OSPF na interface LAN correspondente. Se não estiverem previstos routers OSPF nessa interface, uma Redistribution seletiva delimita o anúncio de forma mais adequada.

4. Substituir valores de interface apenas de forma consciente

Em Override interface configuration, pode selecionar-se a interface de trânsito. Os valores padrão são adequados para muitas ligações Ethernet:

Hello interval: 10 segundos
Dead interval: 40 segundos
Retransmit interval: 5 segundos
Transmit delay: 1 segundo
Interface cost: Auto
Router priority: 1

Hello e Dead têm de ser idênticos em todos os routers do segmento. Retransmit Interval e Transmit Delay são definidos localmente. Cost e Router Priority podem ser deliberadamente diferentes: o Cost determina o caminho de dados preferencial, enquanto a Priority influencia a eleição de DR e BDR em redes broadcast. Uma Priority de 0 exclui a interface desta eleição.

Com a mesma Priority, o Router ID decide, mas uma eleição DR em curso não é preemptive. Um Cost definido manualmente é útil quando se pretende dar preferência a um de vários caminhos. Com Auto, o SFOS calcula o Cost a partir do Reference Bandwidth global e da velocidade configurada da interface. Se a velocidade da ligação for alterada em Network > Interfaces, o OSPF só assume o novo Auto-Cost após um reinício da firewall.

Com autenticação MD5, seleciona-se o Authentication Type MD5 na Area. Em seguida, introduzem-se o mesmo Key ID, de 0 a 255, e a mesma chave na interface de trânsito de ambos os lados.

Os valores de interface alterados são guardados com Save.

5. Anunciar apenas as LANs necessárias

No exemplo, a Firewall A tem de anunciar 10.10.10.0/24 e a Firewall B 10.20.20.0/24. Existem duas formas fundamentalmente diferentes de o fazer:

Uma OSPF Network ativa o OSPF na interface local correspondente. Esta opção é adequada quando outros routers OSPF devem formar aí uma vizinhança.
A Redistribution importa para o OSPF uma rota proveniente de outra origem de routing. Assim, uma LAN diretamente ligada pode ser anunciada sem ser necessária uma vizinhança OSPF nessa interface.

No exemplo, as duas LANs são redistribuídas seletivamente, porque não devem existir outros routers OSPF a formar uma vizinhança nas respetivas interfaces.

A opção Redistribute connected no WebAdmin importa todas as redes diretamente ligadas. Numa firewall de produção, isto também pode incluir redes WAN, de gestão, DMZ, VPN e outras VLANs. Por isso, a caixa de seleção não deve ser ativada sem uma verificação prévia.

Para um anúncio seletivo, pode utilizar-se uma ACL com uma Route Map no CLI do OSPF. Após iniciar sessão por SSH, o caminho passa por 3. Route Configuration > 1. Configure Unicast Routing > 2. Configure OSPF. O exemplo seguinte na Firewall A permite apenas a LAN local 10.10.10.0/24:

enable
configure terminal
access-list ospf-connected-out permit 10.10.10.0/24
route-map ospf-connected-filter permit 10
match ip address ospf-connected-out
exit
router ospf
redistribute connected route-map ospf-connected-filter
exit
write
show running-config

Na Firewall B, utiliza-se 10.20.20.0/24 na access-list. A ACL tem implicitamente uma regra Deny final; por conseguinte, as Connected Routes que não sejam explicitamente permitidas não são redistribuídas através desta Route Map.

Com este procedimento, a opção global Redistribute connected do WebAdmin permanece desativada. Após alterações posteriores à configuração OSPF global, é necessário verificar novamente show running-config, porque o WebAdmin pode remover configurações CLI avançadas que entrem em conflito.

Também Redistribute static exige uma filtragem consciente. Esta opção abrange, entre outras, rotas Blackhole estáticas que, de outra forma, poderiam ser transmitidas involuntariamente aos routers vizinhos.

Verificar e validar o OSPF

Uma vizinhança, por si só, ainda não prova que a LAN pretendida está acessível. A validação é, por isso, efetuada desde a camada OSPF até ao fluxo de pacotes real.

Em Routing > Information > OSPF > Neighbors, o peer deve aparecer com o respetivo Router ID. Full indica que as informações Link-State relevantes foram trocadas na íntegra.
Em Routes, a Firewall A deve ver 10.20.20.0/24 através de 198.51.100.2. A Firewall B deve ver 10.10.10.0/24 através de 198.51.100.1.
Em Interface, verificam-se Area, Router ID, Cost, Timer, Network Type e MTU.
Em Diagnostics > Tools > Route lookup, verifica-se um destino concreto, por exemplo 10.20.20.10 na Firewall A.
Em seguida, testa-se uma ligação real entre um host de cada LAN. O Log Viewer e o Packet Capture devem mostrar a regra de firewall esperada, a interface de trânsito e o tráfego de retorno.

Para os últimos dois passos, é útil Testar uma regra da Sophos Firewall com Log Viewer e Packet Capture.

Para uma verificação adicional por SSH, o caminho no CLI é 3. Route Configuration > 1. Configure Unicast Routing > 2. Configure OSPF:

enable
show ip ospf interface
show ip ospf database
show ip ospf neighbor
show ip ospf route

Estes comandos permitem documentar em conjunto as interfaces envolvidas, a Link-State Database, o estado dos vizinhos e as rotas calculadas pelo OSPF.

Na Advanced Shell, os logs de OSPF e do kernel fornecem contexto adicional. O acesso passa por 5. Device Management > 3. Advanced Shell:

cd /log
tail -f ospfd.log

A saída em curso é terminada com Ctrl+C. Em seguida, pode verificar-se o segundo log:

tail -f zebra.log

O ospfd.log mostra eventos OSPF. O zebra.log ajuda a verificar se uma rota aprendida dinamicamente foi instalada no kernel. Para não acompanhar o log em tempo real, pode utilizar-se, por exemplo, less /log/ospfd.log. O artigo Serviços e ficheiros de log da Sophos Firewall associa outros ficheiros aos serviços responsáveis.

Isolar erros de forma sistemática

Não aparece nenhum Neighbor

Primeiro, verificar a acessibilidade direta dos IPs de trânsito. Em seguida, a interface de trânsito tem de estar up, a OSPF Network tem de corresponder ao IP da interface local e o Dynamic Routing tem de estar ativado na zona correta. Area, máscara de sub-rede, Authentication Type, Key ID, chave, Hello e Dead têm de coincidir em ambos os lados. Router IDs duplicados também impedem uma ligação correta.

O Neighbor permanece em Init ou 2-Way

Init significa que os pacotes Hello estão a chegar, mas que a comunicação ainda não foi confirmada nos dois sentidos. Device Access, filtros assimétricos, atribuição da interface e caminho de retorno são então os primeiros pontos a verificar.

O estado 2-Way é normal numa rede broadcast entre dois routers quando nenhum deles é DR ou BDR. No exemplo com exatamente dois routers OSPF e Priority 1, os dois participantes tornam-se DR e BDR; por isso, a sua vizinhança deve atingir Full. Se permanecer em 2-Way, devem verificar-se Router Priority, Network Type e o peer.

O Neighbor permanece em ExStart, Exchange ou Loading

Nestes estados, a sincronização da Link-State Database começou, mas não termina. As causas mais comuns são valores MTU diferentes, Network Types incompatíveis, Router IDs duplicados ou ligações instáveis. Em Routing > Information > OSPF > Interface, estão disponíveis MTU, MTU Mismatch Detection, Network Type e Timer para comparação.

O Neighbor está em Full, mas falta a LAN remota

Nesse caso, a vizinhança funciona, mas a LAN não está a ser anunciada ou não é permitida pela filtragem. Na firewall emissora, Connected Route, ACL, Route Map e redistribute connected route-map têm de corresponder ao prefixo pretendido. show running-config mostra a configuração OSPF guardada.

Se tiver sido ativado Redistribute connected no WebAdmin, não se deve verificar apenas a LAN em falta, mas também a lista completa de todas as redes anunciadas dessa forma.

A rota existe, mas o tráfego não funciona

O OSPF cumpriu a sua função quando a rota com o Next Hop correto está presente. A partir daí, os erros encontram-se geralmente na regra de firewall, no NAT, na Route Precedence, no caminho de retorno ou no sistema de destino. Em redes de localizações com routing normal, geralmente não é necessário SNAT, porque as duas firewalls devem conhecer as LANs através de OSPF.

OSPF através de IPsec route-based

O OSPF também pode funcionar através de uma interface XFRM de um túnel Site-to-Site IPsec route-based. Num túnel Any-to-Any ou Dual-Stack, atribuem-se às interfaces XFRM de ambos os lados endereços IP únicos da mesma rede de trânsito. Com Traffic Selectors específicos, este endereçamento não é possível.

Para esta variante, aplicam-se ainda as seguintes regras:

O Dynamic Routing é permitido em Administration > Device access para a zona VPN.
A rede de trânsito XFRM é introduzida como OSPF Network.
O tráfego útil necessita de regras de firewall IPv4 ou IPv6 adequadas para a zona VPN.
Hello, Dead, Authentication e MTU têm de corresponder ao peer.
O OSPF Network Type apresentado é comparado em ambos os lados. Uma diferença pode impedir a formação da vizinhança; se não puder ser corrigida no WebAdmin, é necessário ajustar o peer ou contactar o Sophos Support.

Um túnel IPsec verde e um OSPF Neighbor em Full são pontos de verificação distintos. Só a rota aprendida e um fluxo de pacotes real confirmam toda a configuração.

Num cluster HA, o OSPF pode voltar a convergir após um failover. Por isso, deve testar-se um failover planeado e verificar-se depois no Node ativo se o Neighbor, as rotas, o ospfd.log e o zebra.log voltam a apresentar o estado esperado.

OSPFv3 para IPv6

Em Routing > OSPFv3, o routing IPv6 é configurado independentemente do OSPFv2. O Router ID continua a ser um valor único em notação IPv4.

Ao contrário do OSPFv2, não se introduz primeiro uma Network. Em Interfaces, seleciona-se a interface compatível com IPv6 e atribui-se a uma Area. Para uma configuração simples, também aqui se utiliza a Area 0.0.0.0. Hello e Dead têm de coincidir no segmento; Cost, Retransmit, Transmit Delay e Router Priority são definidos de acordo com a topologia. Atualmente, o SFOS suporta apenas uma instância OSPFv3 por interface com o Instance ID padrão 0.

Atualmente, a Sophos Firewall não suporta Authentication para OSPFv3. A troca deve, por isso, ocorrer apenas através de ligações fidedignas ou já protegidas. Uma configuração OSPFv2 existente não anuncia redes IPv6 e o tráfego útil IPv6 requer regras de firewall IPv6 próprias.

No WebAdmin, as redes IPv6 diretamente ligadas e as rotas BGP IPv6 podem ser redistribuídas para OSPFv3. Também neste caso, Redistribute connected inclui todas as redes IPv6 diretamente ligadas e, por isso, não deve ser ativado de forma geral.

A validação é efetuada em Routing > Information > OSPFv3; em caso de erros, o ospf6d.log fornece contexto específico do protocolo.

Reverter a alteração em segurança

Antes de remover o OSPF, tem de existir um caminho alternativo ou uma janela de manutenção planeada para cada rede de destino aprendida. Primeiro, remove-se a Redistribution da LAN local, depois a Network de trânsito e, por fim, desativa-se o Dynamic Routing para a zona. Em seguida, voltam a verificar-se o Route Lookup, a tabela de routing e o acesso de gestão.

Se apenas for necessário reverter um Cost, Timer ou filtro incorreto, deve alterar-se sempre apenas essa configuração. Assim, continua a ser possível identificar se foi afetada a vizinhança OSPF, o anúncio de rotas ou apenas o tráfego útil.