Sostituisci Sophos Firewall Route Precedence in sicurezza

Il Route Precedence dello Sophos Firewall determina l’ordine in cui i diversi tipi di percorso vengono presi in considerazione quando si seleziona il percorso. Sembra un piccolo aggiustamento, ma può avere un impatto immediato sul traffico produttivo. È particolarmente rilevante quando Percorsi statici, Percorsi politici SD-WAN e Percorsi VPN si sovrappongono.

L’articolo spiega quando una modifica ha senso, quando è necessario verificare prima altre cause e come documentare correttamente la modifica utilizzando Device Console, testarla e ripristinarla se necessario. Se si desidera pianificare o testare prima un normale percorso SD-WAN, Sophos Firewall Configurazione e test percorso SD-WAN è adatto.

Quando Route Precedence è importante

Route Precedence diventa importante quando più meccanismi di instradamento teoricamente si adattano alla stessa destinazione. Il firewall deve quindi decidere quale tipo di routing viene valutato per primo.

Situazioni tipiche:

• Una rete di destinazione interna può essere raggiunta tramite un percorso statico e inoltre tramite un percorso politico SD-WAN.
• Uno IPsec VPN basato su percorso utilizza le interfacce XFRM ed è contemporaneamente influenzato dalle regole SD-WAN.
• Un caso speciale IPsec basato su policy funziona con i percorsi IPsec manuali.
• Una vecchia migrazione ha mantenuto route SD-WAN o una Route Precedence precedente.
• Il traffico generato dal sistema o i pacchetti di risposta prendono un percorso imprevisto dopo una modifica SD-WAN.
• Dopo un aggiornamento o una migrazione del firmware, i percorsi esistenti si comportano diversamente dal previsto.

Per i casi speciali IPsec, Route Precedence non è automaticamente la soluzione migliore. Spesso è necessario prima capire se si tratta di un classico problema di routing, di un IPsec Route, di una regola SD-WAN, di NAT o di una regola firewall.

Requisiti

• Sophos Firewall in modalità Gateway.
• Accesso a Device Console, ad esempio tramite SSH.
• Documentazione attuale delle route statiche interessate, delle policy route SD-WAN e delle connessioni VPN.
• Finestra di manutenzione o almeno un percorso di fallback in cui il traffico produttivo potrebbe essere interessato.
• Accesso a Log Viewer e, se necessario, Packet Capture.

Se l’accesso alla console non è ancora configurato, Connetti Sophos Firewall tramite SSH spiega come accedere a Device Console. SSH dovrebbe essere consentito solo da reti attendibili.

⚠️ Importante: una modifica allo Route Precedence ha un effetto globale. Non è interessato solo un singolo tunnel o percorso, ma l’ordine dei tipi di routing sul firewall. Pertanto, non dovresti mai apportare più modifiche di routing, NAT e SD-WAN contemporaneamente.

Ordine predefinito

La documentazione attuale descrive il seguente ordine standard:

1. Statico
2. SD-WAN
3. VPN

I valori nello Device Console sono:

• static
• sdwan_policyroute
• vpn

Importante: la categoria static è più ampia di quanto suggerisca il nome. Sophos vi include reti direttamente connesse, route da ipsec_route, route unicast, route dinamiche e connessioni SSL VPN. Questo è particolarmente rilevante quando si valutano insieme traffico di accesso remoto, route statiche, routing dinamico e regole SD-WAN.

Altrettanto importante: in questo contesto le reti direttamente connesse vengono trattate come percorsi statici. Se sdwan_policyroute si trova di fronte a static e funziona un percorso SD-WAN con una destinazione molto ampia come Any, il traffico interno può improvvisamente dirigersi verso il gateway WAN. Questo è esattamente il motivo per cui static è il punto di partenza sicuro in molti ambienti prima di sdwan_policyroute.

Sui firewall migrati, è importante controllare con particolare attenzione l’output attuale. Sophos può mantenere la Route Precedence di una versione precedente, e le route SD-WAN migrate possono restare legate a vecchie regole firewall. In questo caso non conta il default indicato nella documentazione attuale, ma ciò che system route_precedence show mostra sul firewall specifico.

Quale ordine è corretto?

Non esiste un ordine giusto per ogni progetto. Route Precedence deve adattarsi al modello di percorso.

• Percorsi Internet normali LAN, DMZ, VLAN, accesso remoto e SD-WAN: static sdwan_policyroute vpn Le reti connesse direttamente e i percorsi statici non devono essere sovrascritti dai percorsi SD-WAN ampi.
• IPsec basato su policy si sovrappone a route statiche o SD-WAN: vpn static sdwan_policyroute può aiutare in casi adatti di routing VPN. Se una route statica o locale invia traffico a una zona diversa da WAN, una ipsec_route mirata è spesso più pulita di una modifica globale della precedence. Quindi controllare NAT, regole del firewall e percorso di ritorno.
• L2TP Remote Access o altri casi speciali VPN documentati: Sophos richiede vpn al primo posto in alcuni scenari. Non è uno standard generale, ma una deviazione mirata per un caso d’uso verificato.
• Il failover IPsec route-based o WAN è controllato deliberatamente tramite SD-WAN: L’ordine dipende dal design, spesso con SD-WAN prima di un altro tipo di routing. Testare insieme interfaccia XFRM, criteri SD-WAN, stato del gateway, NAT e Route Precedence.
• MTA, routing speciale o scenari individuali Sophos how-to: L’ordine deve corrispondere allo scenario testato. Non copiare ciecamente da un esempio; controlla sempre reti locali e percorsi di ritorno.

Se un esempio di Sophos mostra un ordine diverso, non si tratta automaticamente di un nuovo standard. Molti esempi risolvono un problema concreto e speciale. Ciò che conta per un firewall produttivo è quali reti di origine e di destinazione siano effettivamente in competizione.

Limite prima della modifica

Route Precedence non dovrebbe essere la prima reazione quando non è possibile raggiungere una rete di destinazione. Per prima cosa dovresti restringere il flusso di pacchetti interessato.

Controlla:

1. Quali fonti e destinazioni sono interessate?
2. Quale zona e quale interfaccia sono coinvolte?
3. Esiste un percorso statico adatto?
4. Esiste un percorso politico SD-WAN più ampio del previsto?
5. Sono presenti route SD-WAN migrate da una versione SFOS precedente?
6. È coinvolta una route VPN o un’interfaccia XFRM?
7. Si applica NAT o MASQ?
8. La regola firewall prevista è soddisfatta nel Log Viewer?
9. Packet Capture mostra il percorso di input e output previsto?

Regola di prova Sophos Firewall con Log Viewer e Packet Capture e Sophos Firewall usa Packet Capture in WebAdmin aiutano per l’esame pratico. Per domande sul NAT, Comprendere il NAT su Sophos Firewall è adatto.

Visualizza l’attuale Route Precedence

I comandi vengono eseguiti nello Device Console, non nello Advanced Shell.

Mostra ordine corrente:

system route_precedence show

L’output dovrebbe essere documentato prima di qualsiasi modifica. È meglio annotare anche la data, il motivo, le reti interessate e il comportamento previsto. Se è necessario un rollback, è necessario impostare nuovamente questo ordine esatto.

Nello WebAdmin puoi anche vedere l’attuale Route Precedence sotto:

Routing > SD-WAN routes

Lì verrà visualizzato nell’area dei consigli di percorso. L’ordine viene modificato tramite Device Console.

Route Precedence modifica

La sintassi è:

system route_precedence set [sdwan_policyroute] [static] [vpn]

L’ordine dei tre valori determina la priorità. Un tipico esempio mette le route statiche davanti alle policy route SD-WAN e alle route VPN:

system route_precedence set static sdwan_policyroute vpn

Se questo ordine è già attivo, probabilmente il problema non riguarda Route Precedence. Quindi dovresti controllare in modo specifico la ricerca del percorso, i percorsi della politica SD-WAN, la configurazione IPsec, il NAT, le regole del firewall e i percorsi di ritorno.

Un altro esempio inserisce le policy route SD-WAN prima delle route statiche:

system route_precedence set sdwan_policyroute static vpn

Ciò può essere intenzionale in alcuni design SD-WAN, ma è rischioso quando regole SD-WAN ampie usano Any o grandi intervalli di rete. In tali casi, l’accesso di gestione, le reti interne o i pacchetti di ritorno possono essere instradati inaspettatamente tramite SD-WAN. L’articolo Sophos Firewall SD-WAN routing per reply packets e system traffic spiega queste interazioni in modo più dettagliato.

Per i casi speciali IPsec basati sulla policy, potrebbe essere necessario in primo luogo anche vpn:

system route_precedence set vpn static sdwan_policyroute

Questa operazione va eseguita solo se le route VPN devono davvero avere priorità nel flusso di pacchetti specifico. Sophos indica che route_precedence non fa prevalere le route VPN sulle route statiche per ogni percorso di destinazione. Se una route statica o locale punta a una zona diversa da WAN, per VPN policy-based con traffic selectors è meglio verificare ipsec_route. Con IPsec route-based e interfacce XFRM, una route SD-WAN o statica pulita è di solito preferibile a mettere vpn globalmente al primo posto.

Prova la modifica

Dopo la regolazione, controlla prima il nuovo ordine:

system route_precedence show

Quindi testa in modo specifico il traffico interessato. Uno stato VPN verde o un percorso esistente non sono prove sufficienti.

Controlla:

• Connessione alla rete di destinazione con ping, test TCP o test dell’applicazione.
• Filtra Log Viewer in base all’origine, alla destinazione e alla regola del firewall.
• Esegui Packet Capture sull’interfaccia di input e output.
• Controlla la ricerca del percorso o la regola SD-WAN interessata.
• Controlla la regola NAT e l’IP di origine tradotto.
• Controllare il percorso di ritorno della stazione remota.
• Accesso alla gestione dei test su WebAdmin e SSH dalle reti di amministrazione pertinenti.

Se sono interessate più sedi, non dovresti controllare solo un client di prova. È meglio avere almeno un client per rete rilevante, un server di destinazione e un accesso remoto o un test VPN se questi percorsi sono interessati dalla modifica.

Ritorno indietro

Un rollback non consiste in un valore predefinito consigliato, ma nell’ordine precedentemente documentato.

Esempio:

system route_precedence set static sdwan_policyroute vpn

oppure:

system route_precedence set sdwan_policyroute static vpn

Controlla di nuovo dopo il rollback:

system route_precedence show

Quindi ripetere gli stessi test di dopo la modifica. Se ciò provoca la restituzione dell’errore originale, ciò è una forte indicazione che Route Precedence è effettivamente coinvolto. Se non cambia nulla, probabilmente la causa è altrove.

Errori comuni

La regola SD-WAN è troppo ampia

Se un percorso politico SD-WAN corrisponde a fonti o destinazioni molto ampie, potrebbe acquisire più traffico del previsto. Ciò è particolarmente pericoloso se SD-WAN ha la priorità su static. L’accesso di gestione o le reti di destinazione interne possono quindi essere eseguiti inaspettatamente tramite un percorso WAN.

Modello tipico:

• Route Precedence è su sdwan_policyroute static vpn.
• Un percorso SD-WAN utilizza Any come destinazione.
• Anche il traffico generato dal sistema o i pacchetti di risposta vengono valutati tramite SD-WAN.

L’accesso a WebAdmin o SSH da una sottorete interna potrebbe quindi andare perso, sebbene il firewall possa ancora essere raggiunto da altre reti.

Lo stato VPN viene confuso con il routing

Un tunnel IPsec attivo dimostra solo che il tunnel è stato negoziato. Ciò non dimostra che il firewall instradi il traffico nel tunnel, che il NAT sia corretto o che la controparte conosca la via del ritorno.

Con IPsec basato su policy, è particolarmente importante verificare se anche route statiche, locali o SD-WAN corrispondono alle subnet remote. vpn static sdwan_policyroute può aiutare in alcuni casi, ma non sostituisce la verifica della zona, dei traffic selectors e di una possibile ipsec_route. Per IPsec route-based occorre prima controllare l’interfaccia XFRM, la route, la route SD-WAN e le regole del firewall.

NAT viene trascurato

Il routing decide dove viene inviato un pacchetto. NAT decide se modificare l’indirizzo di origine o di destinazione. Se un percorso è corretto ma il percorso di ritorno non funziona, spesso è coinvolto il NAT o il percorso di ritorno.

Modifiche multiple contemporaneamente

Se Route Precedence, regole SD-WAN, NAT, regole firewall e parametri VPN vengono modificati contemporaneamente, l’effetto difficilmente può essere attribuito chiaramente. È meglio apportare una modifica, quindi testare e quindi apportare la modifica successiva.

Lista di controllo

• Route Precedence attuale documentato con system route_precedence show.
• Sono state segnalate le fonti, le destinazioni, le reti e i servizi interessati.
• Percorsi statici, percorsi con policy SD-WAN e percorsi VPN controllati.
• Reti direttamente connesse e percorsi di gestione interni presi in considerazione.
• Percorsi ampi SD-WAN identificati con Any.
• Regole NAT e firewall controllate.
• Finestra di manutenzione o percorso di fallback definito.
• Modifica set con ordine esatto.
• Dopo la modifica Log Viewer, Packet Capture e test applicativo eseguito.
• Accesso alla gestione dalle reti di amministrazione controllato.
• Ordine di rollback documentato.

Domande frequenti