SFOS 22: rotas IPsec policy-based no OSPF e BGP

Após uma atualização para o SFOS 22, um túnel IPsec policy-based pode continuar a funcionar enquanto falta um prefixo VPN anteriormente anunciado através de OSPF ou BGP. A vizinhança de routing também pode permanecer em Full ou Established.

A Sophos documenta que o SFOS 22 já não cria as antigas rotas VPN do IPsec policy-based nem utiliza ipsec0 no caminho de transmissão. Se um prefixo OSPF ou BGP desaparecer ao mesmo tempo, trate a relação com a redistribuição como uma inferência operacional observada: a KBA não descreve redistribute kernel, OSPF ou BGP. Por isso, um prefixo em falta não significa automaticamente que o túnel falhou.

⚠️ Não crie uma rota dummy, null, blackhole ou outra rota auxiliar apenas para anunciar o prefixo. Essa rota pode alterar o caminho de dados. Antes de alterar a produção, esclareça o design específico com o Sophos Support ou numa janela planeada de design e manutenção.

Diagnóstico rápido

Investigue este padrão de atualização para o SFOS 22 quando todos os pontos se aplicam:

1. O problema começou com a atualização para o SFOS 22.
2. O túnel é policy-based.
3. O OSPF ou BGP utilizava anteriormente redistribute kernel para o prefixo VPN.
4. O túnel e o Neighbor estão ativos, mas o router recetor não tem o prefixo.

No caso de um túnel route-based ou de uma vizinhança inativa, investigue antes a falha de túnel ou de routing correspondente.

Porque as vistas de routing habituais não são suficientes

A KBA indica que o SFOS 22 já não cria as antigas rotas VPN policy-based. Em separado, descreve as rotas ipsec_route como pertencentes à classe de precedência vpn no SFOS 22 e como ausentes da tabela de routing. Não indica como a redistribuição OSPF ou BGP trata qualquer dos casos.

Avalie separadamente três estados:

• VPN: A ligação IPsec está ativa e o tráfego flui?
• Protocolo de routing: O Neighbor OSPF ou BGP está ativo?
• Anúncio: O router remoto aprende exatamente o prefixo esperado?

Uma VPN verde não prova o anúncio da rota. Inversamente, a ausência de uma rota na vista de routing habitual não prova que um túnel policy-based esteja avariado no SFOS 22.

Identificar o fluxo VPN na saída do conntrack

O SFOS 22 já não utiliza ipsec0 no caminho de transmissão nem cria as antigas rotas VPN. Para a ligação específica em teste, utilize antes os valores do conntrack: o tráfego para a VPN tem mark=0x0, outzone=5 e a flag 74; o tráfego da VPN tem mark=0x0, inzone=5 e a flag 75. A zona 5 é a zona VPN e a flag pode aparecer com outros valores em flagvalues.

Estes valores identificam a direção de uma ligação VPN observada, mas não provam um anúncio OSPF ou BGP. No SFOS 22, também é normal que o Packet Capture não mostre ipsec0 no caminho de transmissão e que o Route Lookup em Diagnostics > Tools possa mostrar a interface WAN. Correlacione um fluxo de teste bem delimitado no conntrack e no Packet Capture, em vez de considerar uma única vista como indicação de falha.

Verificar em segurança e apenas para leitura

Registar dados da firewall e da VPN

1. Registe a versão e a build do SFOS.
2. Em Site-to-site VPN > IPsec, registe o estado da ligação, o tipo de túnel e as sub-redes locais e remotas configuradas.
3. Em Routing > Routing information, execute Route Lookup para um destino específico, tendo em conta a limitação de visualização das rotas VPN policy-based e ipsec_route.
4. Em 4. Device Console, apresente a configuração documentada:

system route_precedence show
system ipsec_route show

Estes comandos não fazem alterações. Route Precedence mostra a ordem global das classes de rota; system ipsec_route show lista as rotas IPsec manuais. Nenhum dos comandos prova, por si só, que o OSPF ou BGP anuncia um prefixo.

Com acesso só de leitura à Advanced Shell, recolha também as vistas de rotas e ligações utilizadas pela KBA:

route -n
ip route show
conntrack -L

Limite a análise conntrack aos endpoints e ao intervalo temporal do teste. Estes resultados podem confirmar a ausência da rota antiga ou de ipsec0 e identificar o fluxo VPN testado; não provam redistribuição nem anúncio.

Verificar a prioridade de ipsec_route antes de a alterar

No SFOS 21.5, uma rota adicionada com ipsec_route pertencia à classe static; no SFOS 22 pertence à classe vpn. Com static sdwan_policyroute vpn, uma rota de política SD-WAN que corresponda aos seletores VPN pode, por isso, captar o tráfego após a atualização. Se o design revisto exigir prioridade para a VPN, a Sophos documenta static vpn sdwan_policyroute como ordem de destino e system route_precedence set static vpn sdwan_policyroute como comando de alteração.

Não aplique esse comando apenas com base neste diagnóstico: a Route Precedence é global e pode afetar outro tráfego. Registe primeiro system route_precedence show, as políticas SD-WAN correspondentes, os caminhos de ida e retorno e um ponto de rollback. Em seguida, utilize Alterar a Route Precedence em segurança para as verificações prévias, a alteração controlada, a validação e o rollback.

Verificar OSPF ou BGP separadamente

Utilize os comandos de visualização documentados pela Sophos no CLI de routing adequado:

show running-config
show ip ospf neighbor
show ip ospf route
show ip bgp

Execute apenas os comandos relativos ao protocolo utilizado. Registe também o prefixo e o Next Hop no router recetor. Consulte Configurar e verificar OSPF e Configurar e verificar BGP para obter as verificações completas.

Tomar a decisão de design

O routing dinâmico é necessário

Para routing dinâmico, a Sophos documenta IPsec route-based Any-to-Any. Este design cria interfaces XFRM que podem ser endereçadas e utilizadas para OSPF ou BGP. A vizinhança e os prefixos anunciados tornam-se então elementos explícitos do design, em vez de efeitos secundários de uma rota VPN policy-based.

Esta é uma direção de design, não um procedimento universal de migração. O endereçamento, os filtros de routing, as regras de firewall, NAT, o caminho de retorno, a redundância e o peer dependem da topologia. Planeie a alteração com o Sophos Support ou numa janela de design e manutenção antes de modificar a produção. Os fundamentos do túnel encontram-se em Configurar VPN IPsec Site-to-Site.

O IPsec policy-based tem de permanecer

A KBA não documenta a redistribuição OSPF ou BGP nem um comando que disponibilize a antiga rota VPN a qualquer dos protocolos. Outra ipsec_route, uma alteração da Route Precedence ou uma rota estática artificial não substitui um design de routing revisto.

Se o IPsec policy-based tiver de permanecer, desenhe com o Sophos Support o caminho de anúncio específico da topologia. A verificação antes da atualização para o SFOS 22 e Criar uma rota IPsec no Sophos Firewall fornecem contexto útil.

Antes de uma alteração em produção

Forneça pelo menos estes dados para uma sessão de suporte ou design:

• versão e build do SFOS, tipo de túnel e estado de HA;
• prefixos locais e remotos anonimizados;
• configuração OSPF ou BGP anterior e estado do Neighbor;
• prefixos esperados e recebidos com os respetivos Next Hops;
• resultados relevantes de Route Lookup, Log Viewer e Packet Capture;
• requisitos de caminho de retorno, NAT, failover e janela de manutenção.

Não altere simultaneamente a VPN, o routing, o NAT e as regras de firewall sem pontos de teste e restauro definidos. Após a aprovação do design, verifique separadamente cada nível planeado: túnel/XFRM, Neighbor, prefixos anunciados, caminhos de ida e retorno e um serviço real.

Distinguir os sintomas

Neighbor ativo, prefixo em falta

Compare o tipo de túnel, a build do SFOS e show running-config. A ausência da antiga rota VPN, uma vizinhança ativa e um prefixo não recebido são observações distintas. Verifique na configuração de routing e no router recetor se a redistribuição dependia dessa rota.

Prefixo presente, tráfego afetado

A redistribuição em falta não é então a causa imediata. Investigue separadamente Route Lookup, regras, NAT e o caminho de retorno.

ipsec_route presente, prefixo em falta

system ipsec_route show confirma apenas a associação manual. Não confirma uma rota normal do kernel nem um anúncio OSPF ou BGP.

Sem sequência universal de rollback

Sem a topologia específica, não existe uma sequência segura para coexistência, comutação, retirada ou failover. Esses passos pertencem ao plano de alteração acordado com o Sophos Support; este artigo não fornece deliberadamente uma sequência de comandos.

FAQ