SFOS 22: redistribute kernel já não distribui rotas IPsec
Após uma atualização para o SFOS 22, o túnel IPsec pode continuar ativo e o Neighbor OSPF ou BGP pode também parecer saudável. Mesmo assim, as redes atrás de um túnel IPsec policy-based deixam subitamente de aparecer nos routers vizinhos.
O motivo típico é redistribute kernel: até ao SFOS 21.5, as rotas VPN policy-based utilizadas neste workflow podiam ser importadas da tabela de routing do kernel. Com o SFOS 22.0 GA, a firewall processa estas rotas internamente no backend da VPN. Por isso, redistribute kernel já não as encontra.
⚠️ Não criar uma rota estática dummy, null ou blackhole apenas para que o prefixo volte a aparecer no OSPF ou BGP. Dependendo da Route Precedence, essa rota pode assumir o caminho de dados e encaminhar o tráfego de produção fora do túnel ou descartá-lo.
Resposta curta: o que fazer agora
Quando uma rede VPN anteriormente anunciada deixa de aparecer após a atualização, verifica-se primeiro se todos os pontos seguintes se aplicam:
- A firewall foi atualizada do SFOS 21.5 ou anterior para o SFOS 22.
- O túnel afetado é policy-based.
- O OSPF ou BGP importava anteriormente as redes VPN através de
redistribute kernel. - O Neighbor mantém-se em Full ou Established, mas o prefixo esperado não aparece no lado recetor.
Se for esse o caso, uma nova entrada ipsec_route não resolve o problema: no SFOS 22, também não cria uma rota normal do kernel. Para um design duradouro e compreensível, recomenda-se IPsec route-based Any-to-Any com interfaces XFRM endereçadas e uma configuração OSPF ou BGP explícita.
A verificação antes da atualização para o SFOS 22 ajuda na preparação. A configuração do túnel encontra-se em Configurar VPN IPsec Site-to-Site.
Porque falta a rota após a atualização
Uma rota do kernel é uma entrada na tabela de routing normal do sistema operativo. Os serviços de routing podem importar essas entradas como origem e, por exemplo, distribuí-las aos Neighbors através de redistribute kernel.
O SFOS 22 trata o IPsec policy-based de forma diferente: o caminho do pacote é determinado através de uma pesquisa interna no backend com marcas, zonas e flags. Assim, o túnel pode encaminhar corretamente, embora a rede VPN associada não apareça como uma rota normal do kernel.
Isto explica o comportamento aparentemente contraditório:
- O túnel IPsec está ativo.
- O OSPF está em Full ou o BGP em Established.
- O tráfego direto através do túnel pode continuar a funcionar.
- No entanto, o prefixo VPN remoto já não é importado da tabela de routing do kernel para o OSPF ou BGP.
A alteração não afeta o OSPF ou BGP em geral. Afeta apenas um design que pressupunha a existência de rotas IPsec policy-based como rotas do kernel.
Reconhecer a dependência antes da atualização
Antes da atualização, não basta verificar se o túnel existente está verde. É necessário determinar de onde o OSPF ou BGP obtém o prefixo a anunciar.
O exemplo utiliza a rede VPN remota 10.60.0.0/16. Trata-se de um valor de ambiente que deve ser substituído pela rede realmente anunciada.
Registar o estado da firewall e da VPN
Em 4. Device Console, documentam-se primeiro a Route Precedence e as rotas IPsec manuais:
system route_precedence show
system ipsec_route show
As saídas respondem a duas perguntas diferentes: Route Precedence mostra a ordem global das classes de routing. system ipsec_route show mostra as associações manuais a túneis policy-based. Nenhum dos comandos prova, por si só, que o OSPF ou BGP está realmente a anunciar o prefixo.
No SFOS 21.5, também se pode registar na Advanced Shell se a rede de exemplo aparece na tabela de routing utilizada para IPsec policy-based:
ip route show table 220 | grep '10.60.0.0/16'
O comando é apenas de leitura; o prefixo de pesquisa deve ser adaptado à rede real. No SFOS 22, a ausência de resultados para IPsec policy-based é esperada e não prova que o próprio túnel esteja avariado.
Documentar OSPF ou BGP separadamente
No CLI de routing correspondente, guarda-se a configuração em execução. Para OSPF, estes comandos apenas de leitura também são úteis:
show running-config
show ip ospf neighbor
show ip ospf route
Para BGP, guarda-se a configuração juntamente com os prefixos BGP conhecidos:
show running-config
show ip bgp
No router recetor, também se regista se 10.60.0.0/16 é aprendido e qual o Next Hop utilizado. Só assim é possível determinar, após a atualização, se o problema afeta o túnel, a vizinhança de routing ou o anúncio do prefixo.
Os procedimentos completos encontram-se em Configurar e verificar OSPF e Configurar e verificar BGP.
Escolher o design de destino seguro
Routing dinâmico através de uma interface XFRM
Quando as redes remotas têm de ser aprendidas ou redistribuídas dinamicamente, o IPsec route-based Any-to-Any é o design de destino compreensível:
- Ambas as extremidades do túnel utilizam Route-based (Tunnel interface) com sub-redes Any-to-Any.
- As interfaces XFRM criadas automaticamente recebem endereços IP exclusivos de uma rede de trânsito própria.
- O OSPF ou BGP estabelece a vizinhança através destes endereços de trânsito.
- As redes previstas são anunciadas explicitamente no protocolo de routing ou redistribuídas através de uma rota real e rigorosamente filtrada.
- As regras de firewall permitem o tráfego útil entre as zonas LAN e VPN.
Deste modo, a rota deixa de ser um subproduto do túnel policy-based. O XFRM, o protocolo de routing e os prefixos anunciados podem ser verificados e alterados separadamente.
A migração é preparada numa janela de manutenção. As ligações policy-based e route-based com os mesmos prefixos não devem estar ativas em simultâneo sem controlo, porque seletores e rotas sobrepostos podem falsear o teste.
Manter temporariamente o IPsec policy-based
Nem todas as ligações existentes têm de ser migradas imediatamente. Se o túnel continuar a ser policy-based, o anúncio dos prefixos necessita, porém, de um design específico da topologia e conscientemente planeado. Os procedimentos do SFOS 22 documentados publicamente não incluem um comando de substituição universal que volte a disponibilizar as rotas VPN do backend como rotas do kernel para OSPF ou BGP.
redistribute static só é adequado quando a própria rota estática é o caminho de dados real pretendido e está limitada aos prefixos previstos através de ACL ou Route Map. Uma rota adicional que serve apenas de origem para a redistribuição não constitui um procedimento padrão seguro.
Alterar system route_precedence também não recupera a rota do kernel em falta. A ordem é global e pode alterar outros caminhos estáticos, SD-WAN e VPN. Se tiver de ser ajustada devido a um conflito de routing concreto, Alterar Route Precedence com segurança explica a verificação e o caminho de retorno.
Validar a migração e o funcionamento
Um teste bem-sucedido inclui vários níveis separados:
- A interface XFRM está ativa e endereçada com o IP de trânsito previsto.
- O OSPF atinge Full ou o BGP Established.
- Apenas os prefixos previstos são anunciados e aprendidos no peer.
- Route Lookup e Routing Information mostram o caminho planeado para um destino concreto.
- Log Viewer e Packet Capture mostram a regra de firewall esperada, bem como a interface de entrada e saída.
- Um serviço real funciona nos dois sentidos e utiliza o caminho de retorno correto.
- Com ligações WAN redundantes ou HA, testa-se separadamente um failover controlado.
Route Lookup verifica o caminho de encaminhamento local, mas não o anúncio do prefixo a um Neighbor OSPF ou BGP. Por isso, são decisivos em conjunto Route Lookup, o prefixo recebido, o Neighbor de routing, o fluxo de pacotes e um teste real da aplicação.
Delimitar o erro sistematicamente
O Neighbor está estabelecido, mas falta o prefixo VPN
Verificar primeiro em show running-config se a rede entrava anteriormente no OSPF ou BGP apenas através de redistribute kernel. Depois, confirmar o tipo de túnel e a build do SFOS. Se se tratar de IPsec policy-based no SFOS 22, a ausência da entrada do kernel é a explicação mais provável; o Neighbor não tem de falhar por esse motivo.
O prefixo é anunciado, mas o tráfego não funciona
Nesse caso, a ausência da redistribuição do kernel já não é a causa imediata. Verificar separadamente Route Lookup, regras de firewall, NAT, caminho de retorno, endereço XFRM e Traffic Selector. Um prefixo anunciado não prova que os caminhos de ida e retorno estejam corretos.
ipsec_route existe, mas OSPF ou BGP não importa a rede
Este comportamento é esperado no SFOS 22. system ipsec_route show mostra a associação manual do túnel configurada, mas não confirma uma rota normal do kernel nem um caminho de dados funcional. Por isso, outra ipsec_route para a mesma rede não recupera redistribute kernel. A classificação exata e a sintaxe Add/Delete segura encontram-se em Criar uma rota IPsec no Sophos Firewall.
O tráfego falha após uma rota estática de substituição
A nova rota pode sobrepor-se ao caminho VPN real. Reverter a alteração com base no comando documentado anteriormente e no plano de manutenção, verificar a Route Precedence e repetir o último teste funcional. Não alterar simultaneamente outras definições de routing, NAT e VPN.
Efetuar um rollback seguro
Antes da migração, registam-se a ligação policy-based, a configuração de routing, a Route Precedence, as regras e os prefixos recebidos. Durante o rollback, apenas se reverte o caminho alterado anteriormente:
- remover de forma controlada os novos anúncios e filtros OSPF/BGP,
- remover as rotas XFRM apenas quando o caminho de dados anterior estiver novamente ativo e verificado,
- repor exatamente a Route Precedence original, caso tenha sido alterada,
- remover completamente as rotas auxiliares artificiais,
- voltar a verificar o túnel, o estado do Neighbor, os prefixos e o tráfego real.
O rollback só está concluído quando o acesso de gestão e as ligações de produção voltarem a funcionar através do caminho original documentado.
FAQ
A ipsec_route recupera a rota do kernel em falta no SFOS 22?
ipsec_route pode continuar a ser necessária em casos especiais justificados de NAT policy-based, mas é processada internamente no SFOS 22 e não fornece uma origem para redistribute kernel.