Configurare e testare una route statica su Sophos Firewall

Una route statica indica a Sophos Firewall tramite quale next hop fisso o interfaccia tunnel raggiungere una determinata destinazione. È adatta quando il percorso è definito e non occorre scegliere in base a source, service, applicazione o qualità della connessione.

Risposta breve

Una route IPv4 si crea qui:

Routing > Static routes > IPv4 unicast route > Add

Per una rete di destinazione 10.20.0.0/24, raggiungibile tramite il router 192.0.2.2 su Port4, inserire:

Destination IP / Netmask: 10.20.0.0/24
Gateway IP: 192.0.2.2
Interface: Port4
Administrative distance: 1
Metric: 10
Description: Branch_10.20_via_Core

Rete di destinazione, gateway e interfaccia devono corrispondere all’ambiente reale. Non riutilizzare Administrative Distance e Metric prima di aver controllato le route esistenti verso la stessa destinazione; 1 e 10 sono solo valori di esempio.

Verificare quindi la destinazione 10.20.0.10 in Diagnostics > Tools > Route lookup. Se il risultato mostra Port4, la decisione di routing è corretta. La modifica è completamente validata solo quando una connessione reale dal client funziona e la risposta ritorna.

Affinché il traffico funzioni, occorrono anche una regola firewall adeguata e una route di ritorno sul dispositivo remoto. Una route statica non autorizza il traffico e non esegue automaticamente il NAT.

Comprendere l’esempio

L’esempio utilizza la seguente struttura:

La rete client dietro Sophos Firewall è 10.10.0.0/24.
Il client di test in questa rete è 10.10.0.10.
Port4 del firewall ha l’IP di transito 192.0.2.1/30.
Il router successivo ha l’IP 192.0.2.2 in questa rete.
Dietro questo router si trova la rete di destinazione 10.20.0.0/24.
Il sistema di test è 10.20.0.10.

La Destination è sempre la destinazione remota, non il router successivo. Gateway IP è il next hop direttamente raggiungibile che inoltra il pacchetto. Interface è la porta o l’interfaccia tunnel tramite cui si raggiunge il next hop.

La destinazione può essere una rete o un singolo host. Se solo il sistema di test deve utilizzare questo percorso, scegliere ad esempio 10.20.0.10/32 per IPv4 o 2001:db8:20::10/128 per IPv6 anziché un’intera rete. Un prefisso più ampio include altri indirizzi di destinazione e va scelto solo se anch’essi sono raggiungibili tramite questo next hop. L’autorizzazione del firewall rimane indipendente.

In Gateway IP si inserisce direttamente l’indirizzo; non occorre un oggetto gateway in Routing > Gateways. Per adattare l’esempio al proprio ambiente, sostituire insieme rete di destinazione, gateway e interfaccia. Se si modifica un solo indirizzo di esempio, la route può essere salvata ma puntare alla rete errata o a un router non raggiungibile. L’IP del gateway deve appartenere alla rete dell’interfaccia selezionata.

Se invece il percorso deve avere un proprio Health Check o essere selezionabile in una SD-WAN Route, seguire la procedura dedicata ai Custom Gateway su Sophos Firewall.

Le basi relative a porta, zona e IP dell’interfaccia sono illustrate in Configurare zone e interfacce Sophos Firewall.

Quando è adatta una route statica

Questo articolo tratta reti di destinazione unicast. Se un mittente deve raggiungere un gruppo multicast attraverso più interfacce, si utilizza la procedura dedicata per configurare il multicast con una route multicast statica.

Il multicast invia un solo flusso a un gruppo invece di copie separate a ogni destinatario, ad esempio per videoconferenze, formazione o distribuzione di software. I destinatari devono aderire al gruppo; mittenti, destinatari e router coinvolti devono supportare il multicast. Gli indirizzi di gruppo IPv4 vanno da 224.0.0.0 a 239.255.255.255, mentre l’indirizzo sorgente rimane unicast. Si tratta dell’intervallo generale, non dell’autorizzazione a utilizzare ogni destinazione in una route multicast statica. In Routing > Static routes, Enable multicast forwarding abilita l’inoltro. Manage multicast route permette di aggiungere, modificare, eliminare e filtrare per IP sorgente, IP multicast, Source Interface o Destination Interface. La procedura multicast collegata spiega prerequisiti, intervallo consentito, test sicuro e rollback.

Una route statica è utile quando una rete è sempre raggiungibile tramite lo stesso next hop, ad esempio:

una rete di filiale dietro un Core Router interno
una rete server dietro uno switch Layer 3
una rete dietro un tunnel RED
una rete remota tramite l’interfaccia XFRM di un tunnel IPsec route-based

Se il firewall deve decidere anche in base a source, service o applicazione oppure cambiare percorso in funzione di latenza, jitter e perdita di pacchetti, una route SD-WAN è generalmente più adatta. Nei domini di routing piccoli o esistenti, RIPv2 può scambiare automaticamente reti semplici. Nelle reti più grandi e soggette a modifiche frequenti, OSPF o BGP riducono il lavoro di manutenzione manuale.

Configurare una route IPv4

Prima della modifica, documentare rete di destinazione, next hop, interfaccia di uscita, zona prevista, percorso di ritorno e un host di test raggiungibile. Quindi:

Aprire Routing > Static routes.
In IPv4 unicast route, fare clic su Add.
In Destination IP / Netmask, inserire 10.20.0.0/24.
In Gateway IP, inserire il router successivo 192.0.2.2.
Selezionare Port4 come Interface.
Impostare Administrative distance su 1.
In Metric, inserire 10.
Aggiungere una Description univoca, ad esempio Branch_10.20_via_Core.
Salvare con Save.

Per questa route, Sophos Firewall considera prima l’interfaccia selezionata e poi il gateway. Se uno dei due campi non è corretto, il next hop previsto non viene raggiunto. Nell’elenco IPv4 è possibile filtrare per indirizzo IP, Gateway IP, Interface o Description e modificare, clonare, eliminare, attivare o disattivare le route. L’elenco IPv6 permette di filtrare per indirizzo IP, Gateway IP o Interface e di aggiungere, modificare o eliminare le route.

Administrative Distance e Metric

L’Administrative Distance valuta le route provenienti da origini di routing concorrenti. Un valore inferiore ha la precedenza: una route con 1 è preferita a una route con 5.

Se più route statiche verso la stessa destinazione hanno la stessa Administrative Distance, decide la Metric. Anche in questo caso viene preferito il valore inferiore.

La Route Precedence globale tra Static, SD-WAN e VPN opera a un livello diverso rispetto ad Administrative Distance e Metric. Non dovrebbe essere modificata frettolosamente per una singola nuova route.

I valori di esempio 1 e 10 sono semplici valori iniziali per una singola route, non un’impostazione generale consigliata dal prodotto. Prima di utilizzarli, confrontare le route esistenti verso la stessa destinazione. Per Primary/Backup o ECMP, Administrative Distance e Metric vengono scelti intenzionalmente in base alla priorità desiderata.

Due route con Administrative Distance diversa possono definire un percorso preferito e uno secondario. Administrative Distance e Metric non controllano però autonomamente la raggiungibilità del next hop. Per una verifica della disponibilità, utilizzare un gateway monitorato in una route SD-WAN. Per selezionare il percorso in base a latenza, jitter o perdita di pacchetti, la route richiede anche un SD-WAN Profile con Best quality o Custom SLA.

Rendere ridondante IPsec route-based con due connessioni Internet presenta un esempio completo con due provider e due tunnel XFRM Any-to-Any. Gateway, route speculari, Route Precedence, Failover e Failback vengono collaudati insieme.

Per IPv4 ECMP, creare più route verso la stessa destinazione con Administrative Distance e Metric identiche, ma next hop diversi. Le connessioni possono così essere distribuite tra next hop di costo equivalente; non si crea un percorso Primary/Backup basato sulla qualità.

Utilizzare Blackhole consapevolmente

Con Blackhole, il firewall scarta il traffico verso la destinazione specificata senza rispondere alla source. Può essere utile per reti intenzionalmente bloccate o aggregate, ma non sostituisce un normale next hop.

Se le route statiche vengono ridistribuite tramite RIP, OSPF o BGP, occorre filtrare in modo mirato le route Blackhole. In caso contrario, il firewall può annunciare questa route di blocco anche ad altri router.

IPv6 e casi particolari con tunnel

In IPv6 unicast route si inseriscono l’indirizzo di destinazione con prefix, il Gateway IP, l’Interface e la Metric. Sophos non documenta per il modulo IPv6 Administrative Distance, opzione Blackhole, Description, Clone o funzione di attivazione e disattivazione. Le impostazioni IPv4 non devono quindi essere applicate a IPv6 senza verificarle.

Per una normale rete IPv6 instradata, procedere così:

In Routing > Static routes > IPv6 unicast route, fare clic su Add.
Inserire una rete di destinazione come 2001:db8:20::/64.
Inserire 2001:db8:4::2 in Gateway IP e selezionare Port4 in Interface.
Scegliere una Metric come 10 dopo aver confrontato le route esistenti e salvare con Save.

L’esempio presuppone 2001:db8:4::1/64 su Port4 e un router direttamente raggiungibile all’indirizzo 2001:db8:4::2. Tutti gli indirizzi IPv6 sono valori di documentazione: sostituirli insieme con quelli del proprio piano di indirizzamento. Prima della modifica, annotare i valori precedenti delle route e garantire un accesso di gestione indipendente. Poi verificare 2001:db8:20::10 con Route lookup, una connessione reale da un client IPv6 e Packet capture con host 2001:db8:20::10; traffico in uscita e risposte devono seguire il percorso previsto. Sono necessarie anche una regola firewall IPv6 e una route di ritorno alla rete client. L’eccezione RED/ARP descritta sotto non dimostra che lo stesso meccanismo valga per IPv6; confermare eventuali casi particolari RED IPv6 per la build installata prima della modifica.

Con un tunnel IPsec route-based con subnet Any-to-Any, la route può puntare direttamente all’interfaccia XFRM senza un gateway separato. Se il tunnel utilizza Traffic Selector specifici, SFOS crea automaticamente la route; in questo caso non si configurano indirizzi IP propri o route aggiuntive sull’interfaccia XFRM. Una route XFRM non corrisponde inoltre al caso particolare CLI ipsec_route, che dipende dalla versione; la distinzione è illustrata in Creare una route IPsec su Sophos Firewall.

Per una rete dietro l’interfaccia peer di un tunnel RED Site-to-Site tra Sophos Firewall si applica un’ulteriore eccezione: inserire come gateway l’IP dell’interfaccia RED peer, ma non selezionare alcuna interfaccia. Il firewall può così determinare tramite ARP l’interfaccia raggiungibile. Configurare Site-to-Site RED tra due Sophos Firewall spiega l’architettura completa di server e client.

Regola firewall, NAT e percorso di ritorno

Il routing determina il percorso. La regola firewall decide se il pacchetto può passare e il NAT ne modifica gli indirizzi quando necessario. Queste tre funzioni vengono configurate separatamente.

Per l’esempio è necessaria una regola dalla rete client 10.10.0.0/24 alla rete di destinazione 10.20.0.0/24. La Destination Zone corrisponde alla zona di Port4. Limitare la regola ai servizi realmente necessari e attivare il logging durante il test.

In una rete di sede normalmente instradata, in genere non si utilizza SNAT, perché il dispositivo remoto deve vedere l’IP reale del client. Il router 192.0.2.2 necessita quindi della seguente route di ritorno:

Rete di destinazione: 10.10.0.0/24
Next Hop: 192.0.2.1

Se non è possibile configurare una route di ritorno sul dispositivo remoto, SNAT può aiutare tecnicamente. Nasconde però l’IP originale del client e deve rimanere una decisione consapevole di progettazione. Le relazioni sono spiegate in Comprendere il NAT su Sophos Firewall.

Route statiche tramite API XML: campi e limiti di modifica

Quando si automatizzano le route statiche, occorre distinguere i campi XML sotto UnicastRoute dalle etichette nell’interfaccia. Le tabelle dei parametri API per SFOS 22.0 e 23.0 documentano quanto segue:

Distance indica la Metric, non l’Administrative Distance: facoltativo, valore predefinito 0, intervallo 0–255.
AdministrativeDistance indica l’Administrative Distance: facoltativo, valore predefinito 1, intervallo 1–255.

Questi valori predefiniti dell’API non sono una raccomandazione per la route mostrata sopra e non dimostrano che i campi omessi rimangano invariati durante un aggiornamento. La priorità desiderata va comunque confrontata con le route esistenti.

L’esempio XML contiene anche OldConfiguration con i precedenti campi di destinazione, gateway, interfaccia e priorità. Tuttavia, nella tabella dei parametri manca una descrizione di questo blocco. L’esempio non dimostra quindi quali campi identifichino la route da modificare, quali valori precedenti siano obbligatori o se le modifiche concorrenti vengano rilevate o confrontate in modo atomico. L’automazione non deve basarsi su questo esempio per garantire la corretta corrispondenza negli aggiornamenti o il controllo della concorrenza.

Anche per i campi degli indirizzi, l’esempio e la tabella presentano incongruenze:

IPFamily: l’esempio mostra IPv4/IPv6, mentre la tabella indica il tipo di dati INTEGER e il valore predefinito IPv4.
DestinationIP: la descrizione menziona indirizzi IPv4/IPv6, ma il tipo di dati è IPADDRESS6.
Netmask: l’esempio mostra 0.0.0.0, mentre la tabella descrive un prefisso di tipo INTEGER nell’intervallo 0–128.

Da queste informazioni non è possibile ricavare una richiesta IPv4/IPv6 universale ed eseguibile. Prima di una modifica tramite API in produzione, chiarire e verificare in un ambiente di test lo schema della richiesta e la corrispondenza univoca con la route esistente per la build installata. Annotare prima i valori precedenti e garantire un accesso di gestione indipendente. Successivamente, verificare i valori della route salvati, Route Lookup e una connessione reale dal client, incluso il percorso di ritorno; il rollback descritto sotto rimane necessario. Finché lo schema o la corrispondenza non sono chiari, effettuare la modifica seguendo la procedura nell’interfaccia descritta sopra, anziché utilizzare una richiesta XML basata su supposizioni.

Per l’eliminazione valgono limiti specifici della documentazione. Le tabelle relative a Delete Unicast Route per SFOS 22.0 e 23.0 indicano DestinationIP e Netmask come campi obbligatori. Questo, tuttavia, non dimostra che costituiscano un selettore completo e univoco per la route da eliminare. Tutte e dieci le celle dei valori predefiniti sono vuote; ciò non implica né il valore 0, né «invariato», né null. Per IPFamily è indicato soltanto il tipo di dati INTEGER, senza alcuna associazione dei valori consentiti a IPv4 o IPv6. Manca un esempio di richiesta Delete.

I valori predefiniti di Add e Update e le ipotesi relative a OldConfiguration descritti sopra non devono quindi essere applicati a Delete. Finché lo schema della richiesta e l’identificazione univoca della route da eliminare non sono chiariti per la build installata, per la rimozione si utilizzano la procedura nell’interfaccia e il rollback descritto sotto, non una richiesta di eliminazione XML basata su supposizioni. Prima si annotano i valori precedenti delle route e si garantisce un accesso di gestione indipendente; dopo si verificano i valori delle route, Route Lookup e una connessione reale dal client, incluso il percorso di ritorno.

Verificare la route

Una route salvata può considerarsi validata solo quando un client reale raggiunge il dispositivo remoto e il percorso di ritorno funziona.

I controlli CLI seguenti vanno eseguiti in 4. Device Console, non nella Advanced Shell, e leggono soltanto lo stato attuale. Prima di eseguirli, verificare la sintassi completa sulla build installata con Tab o ?. Non eseguire comandi incompleti: possono causare il blocco del servizio access_server.

In Diagnostics > Tools > Route lookup, inserire 10.20.0.10. L’output deve mostrare Port4.
Nella Device Console, verificare le route IPv4 o IPv6 configurate e, in caso di concorrenza con SD-WAN o VPN, la Route Precedence:
```
show static-route
show static-route6
system route_precedence show
```
Dal client 10.10.0.10, avviare una connessione reale verso 10.20.0.10, ad esempio Ping o TCP 443, in linea con la regola firewall.
Nel Log viewer, controllare source, destination, service, Firewall Rule ID e un’eventuale NAT Rule ID.
In Diagnostics > Packet capture, utilizzare host 10.20.0.10 per verificare se le richieste escono da Port4 e se arrivano le risposte.

Se Route Lookup mostra il percorso corretto ma il traffico non passa, la causa è generalmente una regola firewall, il NAT, la route di ritorno o il sistema di destinazione. Il test completo del flusso di pacchetti è illustrato in Testare una regola Sophos Firewall con Log Viewer e Packet Capture.

Per problemi di routing più approfonditi, nella Device Console sono utili le ultime voci del log Unicast e del log del kernel:

show logs staticd.log lines 50
show logs zebra.log lines 50

staticd.log riguarda le route Unicast statiche; zebra.log mostra l’installazione delle route Unicast statiche IPv4 nel kernel. Service e file di log Sophos Firewall associa ulteriori file di log ai servizi responsabili.

Dopo il riavvio di un’interfaccia o di un tunnel, una route che specifica solo il gateway può inizialmente non comparire nella tabella di routing. Appare quando il traffico corrisponde alla destinazione e al gateway e il firewall seleziona l’interfaccia. L’assenza della voce subito dopo il riavvio non dimostra quindi ancora un malfunzionamento.

Individuare gli errori ed eseguire il rollback

Route Lookup mostra l’interfaccia errata

Verificare indirizzo di destinazione e prefix; un errore di digitazione può corrispondere a un’altra rete.
Il gateway deve essere direttamente raggiungibile tramite l’interfaccia selezionata.
Confrontare le route statiche concorrenti, Administrative Distance e Metric.
In presenza di SD-WAN o VPN, verificare l’ordine attuale con system route_precedence show. La modifica globale è illustrata in Modificare Route Precedence in sicurezza.

La richiesta esce, ma non arriva alcuna risposta

Verificare la route di ritorno sul router successivo e sul sistema di destinazione.
Verificare la regola firewall per la direzione iniziale e le regole NAT esistenti. Una regola nella direzione opposta è necessaria solo se il dispositivo remoto avvia autonomamente nuove connessioni.
Utilizzare Packet Capture per verificare se la risposta torna su Port4.
Verificare il firewall locale e il default gateway del sistema di destinazione.

Rollback sicuro

Una nuova route IPv4 viene prima disattivata anziché eliminata. Verificare quindi di nuovo Route Lookup, una nuova connessione client e il percorso precedente. Solo dopo aver confermato lo stato iniziale, eliminare se necessario la route e le regole o gli oggetti NAT creati esclusivamente per questa modifica.

Per IPv6, Sophos non documenta una funzione di attivazione e disattivazione. Annotare quindi in anticipo i valori precedenti e, in caso di rollback, modificare o eliminare la nuova route. In un cluster HA, ripetere il test end-to-end dopo un failover sul nuovo Primary.