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. Para um domínio de routing pequeno ou existente com poucos routers, o RIPv2 pode ser mais simples; o OSPF oferece, por outro lado, uma convergência mais rápida e um modelo de caminhos mais escalável.

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.

⚠️ As vizinhanças OSPF devem ser estabelecidas apenas em interfaces de trânsito ou VPN dedicadas e fidedignas. No exemplo, a LAN também é registada como OSPF Network para que o SFOS anuncie o respetivo prefixo. Assim, o SFOS ativa OSPF na interface LAN e pode enviar OSPF Hellos de saída. Dynamic Routing permanece desativado para a zona LAN, para não permitir pacotes OSPF de entrada; isto não impede os Hellos de saída. Não ative Redistribute connected antes de saber quais redes diretamente ligadas serão anunciadas.

Visão geral do processo

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.
Registar a respetiva LAN como segunda rede OSPF ou usar uma redistribuição verificada separadamente.
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.

As rotas OSPF aparecem com as outras rotas unicast. No routing clássico, seleciona-se primeiro o prefixo correspondente mais longo. Para o mesmo prefixo, o SFOS compara a Administrative Distance das fontes de routing; entre caminhos OSPF comparáveis, decide depois a métrica OSPF. Separadamente, a Route Precedence global determina se o routing clássico, as SD-WAN Policy Routes ou as rotas VPN são avaliados primeiro. Antes de uma alteração global, registe a ordem com system route_precedence show.

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 Device Access aplica-se a toda a zona. Uma zona de trânsito dedicada é, por isso, a opção mais clara. Se a interface partilhar a zona, uma Local service ACL exception rule pode restringir IP version, Source zone, Source networks and hosts, Destination host, serviço Dynamic Routing, Action e posição. Contudo, o OSPFv2 utiliza os destinos multicast 224.0.0.5 e 224.0.0.6; o endereço de trânsito local não é necessariamente um Destination host funcional. Confirme o matching multicast na build SFOS instalada. Sem confirmação, a zona dedicada continua a ser a opção segura.

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

⚠️ Os valores de exemplo destinam-se à configuração inicial. Não substituir sem preparação o Router ID de um router existente: a ajuda SFOS 23 avisa que a alteração reinicia todas as sessões OSPF. Isto não significa que versões anteriores estejam isentas. Antes da alteração, garantir cópia de segurança e acesso de gestão independente, registar vizinhos e rotas e planear uma janela de manutenção. Depois, as adjacências previstas devem regressar a Full, os prefixos pretendidos estar presentes, os indesejados ausentes e as ligações reais e respetivos caminhos de retorno funcionar.

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.

Default metric é o valor de recurso para as rotas redistribuídas quando não existe uma métrica específica para o respetivo tipo de rota. Um Area Border Router (ABR) liga outras Areas ao backbone e mantém uma base de dados de topologia e informações de routing separadas para cada Area ligada. O OSPFv2 oferece Standard, Cisco, IBM e Shortcut em ABR type para garantir compatibilidade com o domínio existente; a escolha deve corresponder ao desenho acordado.

Ao migrar de uma versão anterior para SFOS 19.5 ou posterior, o antigo valor predefinido de Reference Bandwidth, 100, passa para 100000 Mbps. Um valor personalizado é mantido sem alteração. Após uma atualização, comparar o valor efetivo e os custos calculados com o planeamento de custos.

Um Autonomous System Boundary Router (ASBR) introduz no OSPF rotas provenientes de outras fontes de routing. As métricas externas seguintes referem-se a esse router.

A métrica predefinida aplica-se às rotas importadas para OSPF. Para rotas redistribuídas e a Default Route anunciada pode escolher-se Metric type. External type 1 soma o custo interno até ao ASBR e o externo. Com External type 2, compara-se primeiro a métrica externa; em caso de igualdade, o caminho interno até ao ASBR desempata. O custo da interface determina a seleção dentro de OSPF. É preferido um custo inferior.

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

Area cost só pode ser definido para tipos de Area diferentes de Normal; o campo não está disponível para a Area backbone deste exemplo. Numa Area Normal, Virtual links > Add permite adicionar uma ligação virtual para ligar ao backbone uma Area sem ligação física a este. Trata-se de uma alteração multiárea planeada, não de uma alternativa à verificação da topologia física.

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.

Para esta configuração simples, a Area 0.0.0.0 mantém o tipo Normal. Uma Stub Area não recebe rotas externas ao AS, enquanto Stub no-summary também suprime as rotas de resumo normais, exceto a rota predefinida. Uma NSSA pode introduzir as suas próprias rotas externas no domínio OSPF como LSA de tipo 7; NSSA no-summary combina esta função com uma restrição mais rigorosa dos resumos. Um Virtual Link só está disponível para uma Normal Area. O tipo de Area não deve ser alterado como medida rápida de troubleshooting, porque ambos os lados e todo o desenho da Area têm de corresponder.

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.

Uma rede OSPF sempre se refere a uma rede local: o SFOS ativa o OSPF em cada interface cujo endereço corresponda à entrada e anuncia o respetivo prefixo. Para a LAN, este exemplo no passo 5 também utiliza uma entrada de rede, pois com isso é possível selecionar e remover exatamente o prefixo desejado no WebAdmin. A desvantagem é que isso também faz com que a interface LAN faça parte do OSPF. Uma redistribuição filtrada evita isso, mas necessita, no SFOS 22, de uma configuração CLI verificada separadamente, incluindo a reversão.

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 interval controla o intervalo entre os pacotes Hello usados para descobrir vizinhos. Dead interval determina quanto tempo se espera sem Hello antes de considerar um vizinho indisponível. O SFOS define automaticamente Dead como quatro vezes Hello; após alterar Hello, verificar se o valor calculado está no intervalo permitido e coincide com o dos vizinhos. Dead também pode ser alterado manualmente. Retransmit interval controla a retransmissão de Link-State Advertisements (LSA); Transmit delay tem em conta os atrasos de transmissão e propagação de uma atualização de estado de ligação.

DR significa Designated Router e BDR, Backup Designated Router. Na eleição, prefere-se a Router Priority mais elevada; em caso de igualdade, vence o Router ID mais elevado.

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, decide o Router ID, mas um novo router com prioridade superior não substitui automaticamente o DR já eleito. 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.

Se for escolhido Text para OSPFv2, introduzir uma palavra-passe de autenticação na interface e acordá-la com o peer. Isto não se aplica ao OSPFv3, que não suporta autenticação.

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:

Um OSPF Network incorpora a interface local apropriada no OSPF e anuncia o respetivo prefixo.
Redistribution assume rotas de outra fonte de routing no OSPF.

Em Routing > OSPF > Networks, clique em Add e atribua a respetiva LAN à Area 0.0.0.0: na Firewall A 10.10.10.0/24, na Firewall B 10.20.20.0/24. Guarde a entrada com Save. Dynamic Routing permanece desativado para a zona LAN; o serviço só é permitido para a zona de trânsito ou para a exceção restrita Local Service ACL. Em seguida, o peer deve aprender exatamente essa LAN. Uma rede local indesejada serve de controlo negativo e não deve aparecer na tabela de encaminhamento OSPF do peer.

Esta variante é adequada enquanto a integração das interfaces LAN no OSPF for intencional. Se o OSPF não dever ser ativado nessas interfaces ou se os prefixos a distribuir vierem de Static, RIP ou BGP, a redistribuição é o método mais apropriado. Contudo, a opção Redistribute connected no WebAdmin inclui todas as redes diretamente ligadas. Numa firewall em produção, isto pode abranger redes WAN, de gestão, DMZ, VPN e outras VLAN. Por isso, a caixa de seleção não deve ser ativada sem uma análise prévia.

No Remote Access SSL VPN, Redistribute connected importa apenas a sub-rede dinâmica dos clientes. Uma sub-rede SSL VPN atribuída estaticamente não é injetada automaticamente e, quando for realmente necessária, tem de ser configurada como uma OSPF Network separada e testada de forma independente.

O WebAdmin não permite filtrar Connected Routes por prefixo individual. A ajuda da linha de comandos do SFOS 22 mostra uma ACL com Route Map para esse fim, mas documenta apenas um exemplo de exclusão, não a reversão completa de uma allowlist em produção. Sem uma reversão validada na versão do SFOS utilizada, não é possível transformar esse exemplo numa receita segura para copiar e colar. Quem precisar de redistribuição seletiva deve planear a ACL e a Route Map como uma alteração de routing separada, confirmar a sintaxe e a reversão para a build instalada e verificar no peer tanto o prefixo pretendido como pelo menos uma rede que explicitamente não pode ser anunciada.

A opção global WebAdmin Redistribute connected permanece desativada em uma variante filtrada por CLI. Após alterações posteriores na configuração global do OSPF, show running-config deve ser verificado novamente, pois o WebAdmin pode remover configurações avançadas de CLI conflitantes e alterações em log-adjacency-changes. Também Redistribute static só será ativado após um inventário completo das rotas estáticas existentes.

Configurar e reverter OSPF na CLI

A partir do SFOS 23.0: os nomes de Access Lists, Prefix Lists e Route Maps devem ser únicos entre todos os protocolos de routing dinâmico, pois partilham uma configuração integrada. Ao atualizar de uma versão anterior para SFOS 23.0 ou posterior, a Sophos Firewall acrescenta automaticamente prefixos de protocolo aos nomes de Route Maps, Prefix Lists e Access Lists se existir um conflito de nomes e atualiza todas as referências às configurações renomeadas. Antes de uma redistribuição seletiva ou da reversão, comparar os nomes dos objetos e as referências guardados antes da atualização com a configuração atual; não presumir que um nome antigo ainda identifica a associação atual. Após a alteração ou a reversão, verificar no peer se os prefixos pretendidos estão presentes e os expressamente proibidos estão ausentes. Inventariar nomes e referências de todos os protocolos antes de escolher nomes ou planear a reversão. Remover apenas as referências desta alteração, não eliminar indiscriminadamente objetos partilhados. Os restantes protocolos devem manter os vizinhos e rotas previstos. Sem sintaxe e reversão confirmadas, não se fornece uma receita de filtragem executável.

SFOS 22, apenas OSPFv2/IPv4: a CLI do OSPF está em 3. Route Configuration > 1. Configure Unicast Routing > 2. Configure OSPF. A configuração mínima abaixo para o Firewall A reproduz o exemplo WebAdmin. Mantém-se a sequência documentada do SFOS 22 com exit e write no contexto global ospf(config)#.

⚠️ Antes de ospf router-id num router existente, aplicar as mesmas verificações prévias de WebAdmin: segundo a ajuda SFOS 23, alterar o Router ID existente reinicia todas as sessões OSPF. Não o substituir pelo valor de exemplo. Garantir cópia de segurança e acesso de gestão independente, registar vizinhos e rotas e usar uma janela de manutenção; verificar depois adjacências Full, prefixos pretendidos/indesejados e tráfego real.

enable
configure terminal
router ospf
ospf router-id 192.0.2.10
network 198.51.100.0/30 area 0
network 10.10.10.0/24 area 0
log-adjacency-changes
exit
write
show running-config
end

SFOS 23, apenas OSPFv2/IPv4: 3. Route Configuration > 1. Configure Unicast Routing abre a consola de routing comum em router# (EXEC). configure terminal passa a router(config)# (configuração global) e router ospf a router(config-ospf)#. A partir de router#, introduzir os comandos sem os prompts apresentados:

router# configure terminal
router(config)# router ospf
router(config-ospf)# ospf router-id 192.0.2.10
router(config-ospf)# network 198.51.100.0/30 area 0
router(config-ospf)# network 10.10.10.0/24 area 0
router(config-ospf)# log-adjacency-changes
router(config-ospf)# end
router# show running-config
router# write

end regressa diretamente a EXEC. A ajuda de configuração SFOS 23 mostra aí show running-config e write, embora a nota exija genericamente do write. O exemplo de filtragem mostra especificamente router(config)# do write após sair de OSPF com exit. Esta tensão documental não prova que EXEC write não guarde: segue-se aqui o exemplo de configuração com modos explícitos, não um simples write no modo de configuração SFOS 23.

show running-config mostra o estado em execução, não uma prova de gravação. Após write no SFOS 23, verificar a confirmação para o ficheiro integrado /conf/routing/frr.conf; o exemplo de filtragem SFOS 22 ainda indica /conf/routing/ospfd.conf. Não editar o ficheiro manualmente. Segundo a Sophos, as alterações CLI devem ser guardadas para aparecerem em WebAdmin e persistirem após reiniciar a firewall ou o daemon. Verificar a confirmação e os valores WebAdmin previstos; não se exige aqui reiniciar e esse teste não foi realizado para este artigo. Se faltar a confirmação, esclarecer com a Sophos antes de outras alterações. Verificar depois vizinhos, rotas e tráfego.

Na Firewall B, utilizam-se o Router ID 192.0.2.20 e a rede LAN 10.20.20.0/24.

O Router ID deve ser único, não pode ser 0.0.0.0 e não precisa de ser um endereço IP realmente atribuído. Sem definição manual, o SFOS utiliza o endereço IP de interface mais elevado. O ID da Area pode ser introduzido como um número de 0 a 4294967295 ou em notação IPv4. O SFOS guarda a rede normalizada de acordo com a máscara; por isso, 198.51.100.1/30 passa a 198.51.100.0/30. É este valor guardado que deve ser usado na verificação e remoção. log-adjacency-changes regista alterações de vizinhos sem modo de depuração e é definido por predefinição numa configuração WebAdmin.

Distinguir Network, processo OSPF e Default Route

SFOS 22, OSPFv2/IPv4: para remover apenas um Network, aplicar no à sua linha normalizada em show running-config, sob router ospf. Antes de remover a rede de trânsito, garantir rotas alternativas, cópia de segurança e acesso de gestão independente e planear uma janela de manutenção: a adjacência desse segmento será perdida.

enable
configure terminal
router ospf
no network 198.51.100.0/30 area 0
exit
write
show running-config
end

Isto termina o OSPF nas interfaces correspondentes e os anúncios afetados desaparecem. Por outro lado, no router ospf remove a configuração de routing OSPFv2. Antes deste passo destrutivo, guardar a configuração completa em execução, criar uma cópia de segurança e assegurar rotas alternativas; o comando deve ser executado numa janela de manutenção e não é um interruptor temporário de ligar/desligar.

SFOS 23, OSPFv2/IPv4: iniciar a mesma remoção do Network em router# na consola comum. A descrição geral SFOS 23 documenta no network em router(config-ospf)#; seguir depois a mesma verificação e gravação em EXEC:

router# configure terminal
router(config)# router ospf
router(config-ospf)# no network 198.51.100.0/30 area 0
router(config-ospf)# end
router# show running-config
router# write

Após a remoção, devem faltar exatamente o Network previsto e o seu anúncio; os restantes vizinhos, rotas alternativas, acesso de gestão e tráfego devem funcionar como planeado. Verificar também a confirmação de gravação. Para reverter esta alteração específica, restaurar a entrada network … area … registada previamente no contexto OSPF adequado à versão, guardar e verificar novamente.

Para remover todo o processo, SFOS 22 indica ospf(config)# no router ospf, enquanto a descrição geral SFOS 23 mostra router(config-ospf)# no router ospf. Trata-se de uma mudança de prompt documentada, não de uma falha de comando demonstrada. Este contexto SFOS 23 não foi confirmado aqui num dispositivo. Por isso, não se fornece um procedimento executável de remoção do processo SFOS 23 até a Sophos confirmar contexto e restauração para a build instalada; não deduzir outro modo. Não eliminar indiscriminadamente ACLs, Prefix Lists ou Route Maps partilhadas.

ospf push-default-route-to-kernel tem uma terceira função separada: uma rota predefinida aprendida por OSPF é instalada na tabela de encaminhamento do kernel. O comando não anuncia uma rota predefinida aos vizinhos e não é o mesmo que Default-information originate. Antes da alteração, documentar as rotas predefinidas existentes, Route Precedence, o caminho de retorno de gestão e o resultado de Route Lookup. A reversão oficialmente documentada é efetuada no prompt OSPF com no ospf push-default-route-to-kernel; depois, verificar novamente a tabela de encaminhamento, Route Lookup, o acesso de gestão e o tráfego real.

As alterações globais no WebAdmin podem remover definições CLI em conflito. Após cada alteração, verificar novamente show running-config, Neighbors, rotas aprendidas e a configuração guardada.

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.
Sob Routes, o Firewall A deve ver 10.20.20.0/24 através de 198.51.100.2. O Firewall B espera 10.10.10.0/24 através de 198.51.100.1. Um prefixo de teste não autorizado, no entanto, não deve aparecer.
Em Interface, verificar Area, Router ID, Cost, Timer, Network Type e MTU. Database mostra a base de dados Link-State; Border routers ajuda a verificar as entradas ABR e ASBR em desenhos multiárea.
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, SFOS 22 usa 3. Route Configuration > 1. Configure Unicast Routing > 2. Configure OSPF; SFOS 23 usa 3. Route Configuration > 1. Configure Unicast Routing para a consola comum. No SFOS 23, regressar a router# com end e executar aí show running-config. Mostra a configuração em execução, não uma prova de gravação; a confirmação separada é explicada acima. Os vizinhos, a base de dados, as interfaces e as rotas calculadas são verificados de forma fiável no SFOS 22 em Routing > Information > OSPF; por isso, este artigo não apresenta comandos show não documentados do daemon de routing.

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

A vizinhança funciona, mas a LAN não é anunciada. Com o método Network deste exemplo, a Connected Route deve estar presente na firewall que anuncia a rede e a entrada network … area … correspondente deve aparecer em router ospf. show running-config mostra o valor normalizado na configuração em execução, não o estado de gravação.

Se for utilizada redistribuição, a fonte de routing escolhida e, quando aplicável, a ACL, a Route Map e redistribute … route-map devem corresponder ao prefixo pretendido. Com Redistribute connected, verificar também a lista completa de todas as Connected Routes anunciadas.

Se, após uma atualização para o SFOS 22, faltar precisamente uma rede atrás de um túnel IPsec policy-based, a causa pode ser uma dependência de redistribute kernel. O túnel e o Neighbor OSPF podem continuar a parecer saudáveis; SFOS 22: rotas IPsec e redistribute kernel explica a verificação e o design XFRM route-based de destino.

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 IPsec Site-to-Site baseado em rota. Para que o SFOS crie as interfaces XFRM, as sub-redes local e remota têm de estar definidas como Any em ambos os lados. A configuração IPv4, IPv6 ou Dual determina as versões de IP utilizadas; com Dual, as regras de firewall separadas para IPv4 e IPv6 são criadas manualmente. Com seletores de tráfego específicos, não surge uma interface XFRM endereçável, à qual se possa atribuir endereços IP ou rotas.

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 tipo de rede OSPF exibido é comparado em ambos os lados. Uma discrepância pode impedir a formação da vizinhança e deve ser esclarecida no projeto dos dois pontos finais.

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.

A documentação oficial de HA não garante a conservação do estado da adjacência OSPF. Num cluster HA, um failover planeado faz, por isso, parte do teste de aceitação da topologia concreta. Depois, no nó ativo, verifica-se se os vizinhos, as rotas, o ospfd.log e o zebra.log apresentam novamente o estado esperado.

OSPFv3 para IPv6

Limite da ajuda CLI SFOS 23: a ajuda de configuração acrescenta router ospf6 e afirma que os mesmos passos se aplicam a OSPFv3, mas continua com comandos Router ID e Network de OSPF IPv4. A ajuda de filtragem acrescenta ACLs IPv6, mas mantém match ip address e router ospf na sequência seguinte. Isto não estabelece um procedimento IPv6 completo e fiável para matching, redistribuição e reversão. Os exemplos CLI acima aplicam-se apenas a OSPFv2/IPv4. Para IPv6, mantém-se o procedimento WebAdmin baseado em interfaces abaixo; usar um procedimento CLI IPv6 apenas após confirmação da Sophos para a build instalada. Não substituir tokens de comandos IPv4 nem considerar comandos upstream FRR como prova de suporte pela Sophos.

Em Routing > OSPFv3, o routing IPv6 é configurado independentemente do OSPFv2. O Router ID permanece um valor único em notação IPv4. Embora o SFOS mostre 0 para Default metric, utiliza o valor não alterável 20; ABR type está fixo em Standard. Auto-cost reference-bandwidth está predefinido como 100000 Mbps. Para Default-information originate existem, tal como no OSPFv2, Never, Regular e Always; no WebAdmin é possível redistribuir rotas IPv6 diretamente ligadas e rotas BGP IPv6.

Ao contrário do OSPFv2, não se adiciona primeiro um Network. Em Interfaces, selecione a interface compatível com IPv6 e atribua-a a uma Area. Para uma configuração simples, utilize também aqui a Area 0.0.0.0. Hello e Dead têm de coincidir no segmento; Cost, Retransmit, Transmit Delay e Router Priority são ajustados à topologia. O SFOS suporta apenas uma instância OSPFv3 por interface. A Instance ID é configurável; o respetivo valor predefinido é 0.

Primeiro, em Routing > OSPFv3 > Interfaces and areas > Areas, clicar em Add, introduzir Area em notação IPv4, escolher Type segundo o desenho e guardar com Save. Para o exemplo simples, a Area é 0.0.0.0. Depois, em Routing > OSPFv3 > Interfaces and areas > Interfaces, clicar em Add, selecionar Interface e introduzir a mesma Area, também em notação IPv4.

Os valores predefinidos do OSPFv3 são Hello 10, Dead 40, Retransmit 5 e Transmit delay 1 segundo, com Router priority 1. As funções dos campos, o cálculo automático de Dead e a verificação do intervalo permitido aplicam-se como explicado no passo da interface OSPFv2. A eleição DR/BDR também prefere a prioridade mais elevada e, em caso de igualdade, o Router ID mais elevado; 0 exclui a interface da eleição. Interface cost pode manter-se em Auto ou ser definido manualmente desmarcando a caixa; os valores inferiores são preferidos. Auto utiliza Reference Bandwidth e a velocidade configurada da interface. Após alterar a velocidade configurada da ligação, o novo Auto-Cost também só é utilizado após um reinício da firewall. Guardar finalmente a configuração da interface com Save.

As Areas OSPFv3 adicionais podem ser criadas como Stub, Stub no-summary, NSSA ou NSSA no-summary. As variantes diferem quanto às LSA externas e de resumo que transportam; uma NSSA pode ainda encaminhar para o ABR LSA de tipo 7 provenientes da sua própria redistribution. Estes tipos de Area pertencem a um desenho multiárea coordenado e não a uma tentativa de reparação improvisada.

Stub não transporta LSA de tipo 4 ou 5 e não permite ligações virtuais. Stub no-summary também suprime as LSA de tipo 3, exceto a rota de resumo predefinida, e não permite ligações virtuais. NSSA não recebe LSA externas de tipo 5 de outras Areas; as suas LSA de tipo 7 circulam dentro da NSSA e o ABR converte-as em LSA de tipo 5 para o backbone. NSSA no-summary suprime os tipos 4 e 5 e o tipo 3, exceto a rota de resumo predefinida, mas mantém o tipo 7 e a sua conversão no ABR. Estas propriedades não significam que o SFOS ofereça redistribuição RIP ou estática no WebAdmin OSPFv3.

Para a configuração global OSPFv3, escolher apenas os anúncios necessários e definir a métrica e o Metric type correspondentes. O significado de E1/E2 e os efeitos de Never, Regular e Always estão explicados no passo global OSPFv2; o aviso sobre Always também se aplica aqui. Aplicar com Apply. Isto pode remover alterações personalizadas a log-adjacency-changes; depois, verificar novamente a configuração em execução e guardada, os vizinhos, os prefixos IPv6 pretendidos e indesejados em Routing > Information > OSPFv3 e o tráfego IPv6 real.

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.

Redistribute connected também redistribui para OSPFv3 todas as redes IPv6 diretamente ligadas e, por isso, não deve ser ativado de forma generalizada. Segundo a Sophos, no Remote Access SSL VPN apenas a sub-rede dinâmica é injetada, não a estática. A ajuda do SFOS 22 menciona uma “rede OSPF” para a sub-rede estática, embora o OSPFv3 seja configurado no WebAdmin através de interfaces em vez de uma lista de redes. Desta contradição não é possível derivar um procedimento seguro; o anúncio de um prefixo IPv6 estático para SSL VPN deve ser esclarecido junto da Sophos para o build instalado.

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, deve existir um caminho alternativo ou uma janela de manutenção planeada para cada rede de destino aprendida. No exemplo, remove-se primeiro a entrada Network da LAN, depois a Network de trânsito e, por último, desativa-se Dynamic Routing para a zona de trânsito. Se a LAN for redistribuída, essa redistribuição é revertida primeiro. Em seguida, verificam-se novamente Route Lookup, a tabela de encaminhamento 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.