SFOS 22: route IPsec policy-based in OSPF e BGP

Dopo un upgrade a SFOS 22, un tunnel IPsec policy-based può continuare a funzionare mentre manca un prefisso VPN precedentemente annunciato tramite OSPF o BGP. Anche l’adiacenza di routing può rimanere Full o Established.

Sophos documenta che SFOS 22 non crea più le precedenti route VPN per IPsec policy-based e non usa più ipsec0 nel percorso di trasmissione. Se contemporaneamente scompare un prefisso OSPF o BGP, trattare il collegamento con la ridistribuzione come un’inferenza operativa osservata: la KBA non descrive redistribute kernel, OSPF o BGP. Un prefisso mancante non significa quindi automaticamente che il tunnel sia guasto.

⚠️ Non creare una route dummy, null, blackhole o un’altra route ausiliaria esclusivamente per annunciare il prefisso. Può modificare il data path. Prima di intervenire in produzione, chiarire il design specifico con Sophos Support o in una finestra pianificata di progettazione e manutenzione.

Diagnosi rapida

Esaminare questo scenario di upgrade a SFOS 22 quando si applicano tutti i punti seguenti:

1. Il problema è iniziato con l’upgrade a SFOS 22.
2. Il tunnel è policy-based.
3. OSPF o BGP utilizzava in precedenza redistribute kernel per il prefisso VPN.
4. Il tunnel e il Neighbor sono attivi, ma sul router ricevente manca il prefisso.

In presenza di un tunnel route-based o di un’adiacenza non attiva, esaminare invece il relativo problema del tunnel o del routing.

Perché le normali viste di routing non sono sufficienti

La KBA indica che SFOS 22 non crea più le precedenti route VPN policy-based. Separatamente, descrive le route ipsec_route come appartenenti alla classe di precedenza vpn in SFOS 22 e come assenti dalla tabella di routing. Non indica come la ridistribuzione OSPF o BGP gestisca i due casi.

Valutare separatamente tre stati:

• VPN: la connessione IPsec è attiva e il traffico passa?
• Protocollo di routing: il Neighbor OSPF o BGP è attivo?
• Annuncio: il router remoto apprende esattamente il prefisso previsto?

Una VPN verde non dimostra l’annuncio della route. Al contrario, una route mancante nella normale vista di routing non dimostra che un tunnel policy-based sia guasto in SFOS 22.

Identificare il flusso VPN nell’output conntrack

SFOS 22 non utilizza più ipsec0 nel percorso di trasmissione e non crea più le precedenti route VPN. Per la connessione specifica sottoposta a test, utilizzare invece i valori conntrack: il traffico verso la VPN presenta mark=0x0, outzone=5 e il flag 74; il traffico dalla VPN presenta mark=0x0, inzone=5 e il flag 75. La zona 5 è la zona VPN e il flag può comparire insieme ad altri valori in flagvalues.

Questi valori identificano la direzione di una connessione VPN osservata, ma non dimostrano un annuncio OSPF o BGP. In SFOS 22 è inoltre normale che Packet Capture non mostri ipsec0 nel percorso di trasmissione e che Route Lookup in Diagnostics > Tools possa mostrare l’interfaccia WAN. Correlare un flusso di test ben delimitato in conntrack e Packet Capture invece di considerare una singola vista come indicazione di un guasto.

Verificare in sicurezza e in sola lettura

Registrare i dati del firewall e della VPN

1. Registrare la versione e il build di SFOS.
2. In Site-to-site VPN > IPsec, registrare lo stato della connessione, il tipo di tunnel e le sottoreti locali e remote configurate.
3. In Routing > Routing information, eseguire Route Lookup per una destinazione specifica tenendo conto della limitazione di visualizzazione per le route VPN policy-based e ipsec_route.
4. In 4. Device Console, visualizzare la configurazione documentata:

system route_precedence show
system ipsec_route show

Questi comandi non apportano modifiche. Route Precedence mostra l’ordine globale delle classi di route; system ipsec_route show elenca le route IPsec manuali. Nessuno dei due comandi dimostra da solo che OSPF o BGP annunci un prefisso.

Con accesso in sola lettura all’Advanced Shell, acquisire anche le viste di route e connessioni utilizzate dalla KBA:

route -n
ip route show
conntrack -L

Limitare l’analisi conntrack agli endpoint e all’intervallo temporale del test. Questi output possono confermare l’assenza della vecchia route o di ipsec0 e identificare il flusso VPN testato; non dimostrano ridistribuzione o annuncio.

Verificare la priorità di ipsec_route prima di modificarla

In SFOS 21.5, una route aggiunta con ipsec_route apparteneva alla classe static; in SFOS 22 appartiene alla classe vpn. Con static sdwan_policyroute vpn, una policy route SD-WAN che corrisponde ai selettori VPN può quindi acquisire il traffico dopo l’upgrade. Se il design verificato richiede la priorità della VPN, Sophos documenta static vpn sdwan_policyroute come ordine di destinazione e system route_precedence set static vpn sdwan_policyroute come comando di modifica.

Non applicare il comando basandosi solo su questa diagnosi: Route Precedence è globale e può influire su altro traffico. Registrare prima system route_precedence show, le policy SD-WAN corrispondenti, i percorsi di andata e ritorno e un punto di rollback. Utilizzare quindi Modificare Route Precedence in sicurezza per le verifiche preliminari, la modifica controllata, la validazione e il rollback.

Verificare OSPF o BGP separatamente

Utilizzare i comandi di visualizzazione documentati da Sophos nella CLI di routing appropriata:

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

Eseguire solo i comandi relativi al protocollo in uso. Registrare inoltre il prefisso e il Next Hop sul router ricevente. Consultare Configurare e verificare OSPF e Configurare e verificare BGP per le verifiche complete.

Prendere la decisione sul design

È necessario il routing dinamico

Per il routing dinamico, Sophos documenta IPsec route-based Any-to-Any. Questo design crea interfacce XFRM che possono essere indirizzate e utilizzate per OSPF o BGP. L’adiacenza e i prefissi annunciati diventano così elementi espliciti del design, anziché effetti secondari di una route VPN policy-based.

Questa è una direzione progettuale, non una procedura di migrazione universale. Indirizzamento, filtri di routing, regole firewall, NAT, percorso di ritorno, ridondanza e peer dipendono dalla topologia. Pianificare la modifica con Sophos Support o in una finestra di progettazione e manutenzione prima di intervenire in produzione. I principi del tunnel sono descritti in Configurare una VPN IPsec Site-to-Site.

IPsec policy-based deve rimanere

La KBA non documenta la ridistribuzione OSPF o BGP né un comando che renda disponibile ai protocolli la precedente route VPN. Un’altra ipsec_route, una modifica di Route Precedence o una route statica artificiale non sostituiscono un design di routing verificato.

Se IPsec policy-based deve rimanere, progettare con Sophos Support il percorso di annuncio specifico per la topologia. Il controllo per l’upgrade a SFOS 22 e Creare una route IPsec su Sophos Firewall forniscono un contesto utile.

Prima di una modifica in produzione

Fornire almeno questi dati per una sessione di supporto o progettazione:

• versione e build di SFOS, tipo di tunnel e stato HA;
• prefissi locali e remoti anonimizzati;
• configurazione OSPF o BGP precedente e stato del Neighbor;
• prefissi previsti e ricevuti con i relativi Next Hop;
• risultati pertinenti di Route Lookup, Log Viewer e Packet Capture;
• requisiti per percorso di ritorno, NAT, failover e finestra di manutenzione.

Non modificare contemporaneamente VPN, routing, NAT e regole firewall senza punti di test e ripristino definiti. Dopo l’approvazione del design, verificare separatamente ogni livello pianificato: tunnel/XFRM, Neighbor, prefissi annunciati, percorsi di andata e ritorno e un servizio reale.

Distinguere i sintomi

Neighbor attivo, prefisso mancante

Confrontare tipo di tunnel, build di SFOS e show running-config. L’assenza della precedente route VPN, un’adiacenza attiva e un prefisso non ricevuto sono osservazioni distinte. Verificare nella configurazione di routing e sul router ricevente se la ridistribuzione dipendeva da quella route.

Prefisso presente, traffico compromesso

La mancata ridistribuzione non è quindi la causa immediata. Esaminare separatamente Route Lookup, regole, NAT e percorso di ritorno.

ipsec_route presente, prefisso mancante

system ipsec_route show conferma solo l’associazione manuale. Non conferma né una normale route del kernel né un annuncio OSPF o BGP.

Nessuna sequenza di rollback universale

Senza la topologia specifica non esiste una sequenza sicura per coesistenza, commutazione, ritiro o failover. Questi passaggi appartengono al piano di modifica concordato con Sophos Support; questo articolo non fornisce deliberatamente una sequenza di comandi.

FAQ