Vai al contenuto
Avanet
Accedi

Configurare e testare route SD-WAN Sophos Firewall

Sophos Firewall

Con una route SD-WAN si controlla attraverso quale gateway passa un flusso di traffico definito su Sophos Firewall. È utile con più connessioni Internet, MPLS, VPN IPsec route-based, VoIP o servizi cloud. La route deve essere definita in modo preciso e testata con traffico reale, altrimenti può includere reti interne o usare la Public IP errata durante il failover.

Se Sophos Fusion (in precedenza Sophos Central) deve generare tunnel route-based e percorsi tra sedi per più firewall gestiti, occorre invece seguire Configurare e verificare un gruppo di connessioni SD-WAN in Sophos Fusion. Questo articolo spiega la route SD-WAN locale, che resta importante anche per verificare i percorsi distribuiti centralmente.

Risposta breve

Una route SD-WAN si crea qui:

Routing > SD-WAN routes > IPv4 / IPv6 > Add

Prima devono essere chiari quattro punti:

  • quale traffico deve corrispondere in base a incoming interface, source, destination e service
  • quale primary/backup gateway o SD-WAN profile deve essere utilizzato
  • se sono consentiti esclusivamente questi gateway e quale NAT è adatto
  • come verificare route, gateway e percorso di ritorno con Log Viewer e Packet Capture

Per destinazioni IPv4 pubbliche non si dovrebbe usare Any indiscriminatamente, ma quando possibile Internet IPv4 group o destinazioni specifiche. Se SD-WAN precede Static nella route precedence, una route Any troppo ampia può inviare anche traffico interno al gateway WAN.

Il video integra la guida alla pianificazione, configurazione e verifica delle route SD-WAN su Sophos Firewall.

Utilizzo e pianificazione

Quando preferire SD-WAN a una route statica

Una route statica è sufficiente se una rete di destinazione è sempre raggiungibile tramite un next hop fisso. Le route SD-WAN aggiungono criteri come source, service, utente o applicazione e possono scegliere i gateway in base a disponibilità o qualità.

Casi tipici:

  • instradare determinati client o servizi tramite WAN2 e passare a WAN1 in caso di guasto
  • inviare VoIP o applicazioni cloud su un percorso con bassa latenza e perdita di pacchetti
  • utilizzare MPLS, LTE/5G o un tunnel IPsec route-based come percorso primario o di backup
  • vincolare il traffico a un provider la cui Public IP è autorizzata su un sistema remoto

Esempio di pianificazione e requisiti

Prima di creare la route si descrive un flusso concreto. Per il traffico Microsoft 365, la pianificazione potrebbe essere:

  • Incoming interface: interfaccia LAN interna
  • Source network: Client_Net_10.20.0.0_24
  • Destination: gruppo di destinazioni Microsoft 365 gestito internamente o Internet IPv4 group
  • Services: HTTPS e, se necessario, un gruppo di servizi per UDP 3478-3481
  • Primary gateway: WAN2
  • Backup gateway: WAN1
  • Fallback: consentire la default route o attivare Route only through specified gateways
  • NAT: MASQ o IP SNAT fisso adatto al gateway selezionato
  • Test: IP client, destinazione, gateway previsto e voce di log prevista

Servono inoltre regole firewall adeguate, regole NAT per il traffico da tradurre, logging firewall attivo e accesso a Log viewer e Diagnostics > Packet capture. I gateway WAN sono in Network > WAN link manager; i custom gateway per MPLS, RED o XFRM si creano in Routing > Gateways.

Il comportamento generale Active/Backup del percorso WAN predefinito è descritto in Configurare il failover WAN su Sophos Firewall; per le basi relative a interfacce e gateway, consultare Configurare zone e interfacce Sophos Firewall.

Con IPsec route-based, la direzione è importante: Un’interfaccia XFRM come Incoming interface corrisponde al traffico che entra dal tunnel. Per traffico da LAN a VPN si seleziona invece il gateway dell’interfaccia XFRM come primary gateway o in un SD-WAN profile. Le basi sono in Creare una route IPsec su Sophos Firewall.

Per un esempio Teams più mirato, aggiungere il gruppo fittizio Sales_Team in Users or groups e Teams_VoIP in Application objects. Sostituire entrambi i nomi con il proprio gruppo utenti e le applicazioni effettivamente necessarie. Insieme all’interfaccia LAN, a Client_Net_10.20.0.0_24, alle destinazioni e ai servizi previsti, questi criteri indirizzano solo il flusso corrispondente tramite WAN2/WAN1. Verificare separatamente una regola di autorizzazione restrittiva da LAN a WAN per questa sorgente, destinazioni e servizi, i permessi utente previsti e NAT su entrambi i percorsi. La route SD-WAN non concede accesso; il test deve confermare utente, applicazione, Firewall Rule ID e NAT ID previsti.

Due WAN con priorità opposte

Per la LAN 10.20.0.0/24, alcune destinazioni pubbliche devono utilizzare preferibilmente WAN1, mentre le altre destinazioni IPv4 pubbliche devono passare da WAN2. Ogni linea funge da backup dell’altra. Questo esempio di pianificazione integra la procedura SFOS-22; la documentazione SFOS-23-EAP conferma il meccanismo dei profili, ma non costituisce un’approvazione per qualsiasi build.

⚠️ Le nuove route e il loro ordine modificano il percorso dei dati. Prima salvare posizioni delle route, stati On/Off, valori dei profili, NAT e Route Precedence attuale, quindi verificare un accesso di gestione indipendente. Eseguire test di guasto solo nella finestra di manutenzione approvata; non eliminare o modificare gateway o profili condivisi per simulare un guasto.

  1. In Routing > SD-WAN profiles > Add, creare due profili separati con Routing strategy: First available gateway: Ziele_WAN1_WAN2 nell’ordine WAN1, WAN2, e Internet_WAN2_WAN1 nell’ordine WAN2, WAN1. Nomi, LAN e gateway sono valori di esempio adattabili. Attivare Health check in entrambi; lasciare SLA disattivato per questa scelta basata solo sulla disponibilità. Scegliere destinazioni delle sonde, protocollo e contatori secondo la procedura di health check descritta sotto, senza accettare ciecamente i valori predefiniti. Le destinazioni devono permettere di rilevare anche guasti oltre il gateway del provider, non solo la sua raggiungibilità locale.
  2. In Routing > SD-WAN routes > IPv4 > Add, creare la route specifica LAN_Ziele_WAN1: Incoming interface è l’interfaccia LAN effettiva, Source networks l’oggetto per 10.20.0.0/24, Destination networks il gruppo aggiornato delle destinazioni pubbliche selezionate e Services solo i servizi necessari. Selezionare Ziele_WAN1_WAN2. Per i domini, considerare prima i limiti di host e gruppi FQDN; un nome di dominio non garantisce un intervallo IP di destinazione esclusivo.
  3. Sotto di essa creare LAN_Internet_WAN2 con la stessa interfaccia LAN e rete sorgente, Destination networks: Internet IPv4 group, i servizi Internet approvati e Internet_WAN2_WAN1. La route specifica deve stare sopra quella Internet generale. Non usare una route globale Any; le destinazioni interne e VPN non appartengono a questo percorso Internet.
  4. Impostare consapevolmente Route only through specified gateways per entrambe: in questo esempio è attivo, così nessun altro percorso subentra se entrambi quelli previsti si guastano. Verificare separatamente autorizzazioni firewall e MASQ/SNAT per le due WAN. Se il peer richiede un IP pubblico fisso, deve consentire anche l’IP di backup.

Per la verifica, creare una nuova connessione verso una destinazione specifica e una delle altre destinazioni pubbliche: inizialmente sono attesi rispettivamente WAN1 e WAN2. Poi, in un ambiente di test approvato, provare separatamente entrambi i guasti a monte, anche con interfaccia fisica ancora attiva: se si guasta WAN1, le nuove connessioni di entrambe le classi devono funzionare via WAN2; se si guasta solo WAN2, via WAN1. Dopo ogni ripristino confrontare le nuove connessioni con la priorità prevista e osservare separatamente le sessioni esistenti. Documentare route, gateway e SNAT/IP pubblico nei log o in Packet Capture, quindi ricontrollare DNS, HTTPS e l’accesso di gestione interno. Non ne derivano un tempo di commutazione fisso o la continuità delle sessioni esistenti.

Se il percorso è inatteso, non ampliare i criteri: confrontare prima corrispondenze delle route, ordine, stato di salute e NAT. Per il rollback, disattivare le nuove route oppure ripristinare valori e ordine di route, profili e NAT documentati prima; poi ricontrollare stato ed entrambi i flussi di test. Senza una simulazione di guasto isolabile, questa parte della verifica resta aperta. I limiti dettagliati per sessioni e SNAT sono riportati sotto nella sezione sui Testare failover e failback in sicurezza.

MPLS tra filiale e sede centrale

Un esempio circoscritto collega 10.20.0.0/24 nella filiale ai server web della rete centrale 10.30.0.0/24: l’interfaccia in ingresso è la LAN della filiale, il primary gateway è MPLS-1, il backup è MPLS-2 e i servizi sono limitati ai TCP 80/TCP 443 necessari. Il firewall centrale richiede la corrispondente route di ritorno da 10.30.0.0/24 a 10.20.0.0/24 tramite i propri gateway MPLS. Reti, interfacce, gateway e servizi sono valori di esempio da adattare alla topologia reale. La regola firewall separata della filiale consente LAN verso la zona MPLS effettiva, qui MPLS_DMZ, solo per queste reti e servizi; anche le regole centrali devono consentire il flusso previsto. Questo design instradato mantiene gli indirizzi privati originali senza SNAT. Non è una regola NAT universale per ogni installazione MPLS. Verificare entrambe le direzioni e il Source IP invariato con traffico reale sui due firewall.

Configurare la route SD-WAN

Definire i criteri di corrispondenza

Per IPv6, selezionare host IP di destinazione specifici anziché una destinazione generica Any. Se una route generale Any deve rimanere, creare sopra di essa una route per gli host IP di destinazione specifici e il gateway previsto; mantenere limitati anche incoming interface, source e services. Prima di modificare qualcosa, registrare l’ordine installato con system route_precedence show, la posizione e le impostazioni della route, verificare un accesso di gestione indipendente e pianificare il ripristino di questi valori. Una route più specifica non giustifica il reset indiscriminato della precedenza globale.

  1. Aprire Routing > SD-WAN routes.
  2. Selezionare IPv4 o IPv6 e fare clic su Add.
  3. Inserire un nome univoco come Clients_M365_WAN2.
  4. Selezionare l’Incoming interface da cui entra il traffico da controllare.
  5. Se necessario, selezionare un valore DSCP se i pacchetti in ingresso sono marcati in modo affidabile.
  6. Definire le Source networks e aggiungere Users or groups se necessario.
  7. Limitare il più possibile le Destination networks.
  8. Limitare i Services ai protocolli e alle porte necessarie.
  9. Se necessario, selezionare gli Application objects.
  10. In Link selection settings, scegliere un SD-WAN profile o primary/backup gateway.
  11. Attivare o disattivare consapevolmente Route only through specified gateways.
  12. Salvare la route e spostarla nella posizione corretta; vince la prima route SD-WAN corrispondente.
  13. Testare con un client e una destinazione definiti.

Gli Application Objects richiedono una Web Protection License attiva. La prima connessione viene instradata in base a destination IP, porta, protocollo e incoming interface tramite un’altra route SD-WAN corrispondente oppure, in mancanza, tramite la default route. L’Application Object si applica alle connessioni successive solo dopo il riconoscimento dell’applicazione. I dati di classificazione hanno una TTL di 3600 secondi dall’avvio della sessione. Per le Micro Apps, solo DPI Engine Mode supporta tutte le applicazioni; Web Proxy Mode supporta solo Pattern Applications e Synchronized Security Applications.

In un cluster HA, SFOS sincronizza questa cache di Application Routing tramite il link HA dedicato usando multicast 226.1.1.1 sulla porta 4455. Un riavvio del firewall cancella i dati di classificazione. Dopo un riavvio o un problema HA, non basta quindi controllare lo stato del tunnel o del gateway; occorre generare di nuovo una prima connessione applicativa e una connessione successiva.

Creare un Application Object

Il motore DPI può riclassificare un’applicazione nella stessa connessione, ad esempio passando da un sito web alla sua chat. La nuova decisione si applica alle connessioni successive; non garantisce il reindirizzamento della connessione in corso. Se non inizia un’altra sessione entro la TTL di 3600 secondi dall’avvio della sessione, i dettagli di sessione memorizzati vengono eliminati.

Gli Application Objects possono includere applicazioni web, micro app, Synchronized Security Applications rilevate sugli endpoint, applicazioni personalizzate e categorie di applicazioni. Scegliere il tipo in base al riconoscimento necessario e rispettare i limiti di licenza e DPI/proxy descritti sopra; una categoria intera è più ampia di una singola applicazione necessaria.

Un Application Object raggruppa solo le applicazioni che devono utilizzare lo stesso percorso SD-WAN. Aprire Applications > Application object, selezionare Add, assegnare un nome e restringere i risultati tramite Category, Risk, Characteristics, Technology, Classification o la ricerca per nome. Selezionare quindi le applicazioni effettivamente necessarie e salvare l’oggetto. Sophos aggiorna dinamicamente l’elenco delle applicazioni disponibili tramite gli aggiornamenti IPS e Synchronized Application Control; è quindi opportuno ricontrollare la selezione dopo modifiche ai pattern o alle applicazioni.

Il filtro Technology distingue browser-based, client-server, network protocol, P2P e synchronized application control. In Classification sono disponibili new, sanctioned, unsanctioned e tolerated. Questi criteri facilitano la selezione, ma non dimostrano che la route successiva funzioni. Per verificarlo servono prima la connessione di classificazione e poi una nuova connessione di test.

Per Microsoft 365, un unico oggetto collettivo è spesso troppo ampio. Un oggetto come Teams_VoIP può contenere solo le applicazioni Teams destinate alla comunicazione in tempo reale, mentre OneDrive o SharePoint utilizza un altro percorso. Selezionare poi l’oggetto salvato nel campo Application objects della route SD-WAN.

Scegliere gateway o SD-WAN profile

I primary/backup gateway sono sufficienti per un percorso preferito e un fallback. Un SD-WAN profile separa due decisioni: Routing strategy sceglie il percorso con First available gateway o Load balancing; il Service Level Agreement (SLA) opzionale aggiunge misure di qualità a tale strategia. Best quality e Custom SLA non sono quindi due ulteriori strategie di routing.

Configurare un SD-WAN profile in Routing > SD-WAN profiles > Add come segue:

  1. Inserire nome e descrizione, quindi scegliere First available gateway o Load balancing in Routing strategy.
  2. Assegnare da due a otto gateway e trascinarli nell’ordine desiderato. Gateway weights compare solo con il load balancing; pesi diversi possono rappresentare capacità differenti dei collegamenti.
  3. Per il load balancing scegliere Round-robin o un Session persistence type adatto. La persistenza può basarsi su source IP, destination IP, source e destination oppure su una singola connessione.
  4. Attivare SLA solo se latenza, jitter o perdita di pacchetti devono influire sulla scelta. Best quality confronta un solo criterio. Custom SLA verifica latenza, jitter e perdita di pacchetti rispetto alle soglie impostate.
  5. Attivare Health check, scegliere Ping o TCP in Protocol e inserire fino a due Probe targets. Con TCP indicare anche una porta sulla quale il target risponde in modo affidabile. SFOS attiva obbligatoriamente l’Health Check quando lo SLA è attivo.
  6. Impostare Interval between checks, Response time-out, Deactivate gateway after, Activate gateway after e Sample size for SLA in base al servizio. Queste impostazioni hanno ruoli diversi: Interval between checks e Response time-out regolano le sonde; Deactivate gateway after conta i tentativi falliti e Activate gateway after le risposte riuscite. Sample size for SLA definisce il numero di campioni per le prestazioni medie del gateway. Regolare separatamente il rilevamento dei guasti e la riattivazione; i cinque valori non costituiscono un unico timer di failover.
  7. Salvare il profile, selezionarlo nella route SD-WAN e verificare il percorso con traffico reale.

I due Probe Targets costituiscono un unico test di disponibilità: SFOS considera il gateway attivo se almeno uno risponde. Se il primo non risponde, passa al secondo e continua a usarlo finché risponde. Il ritorno del primo, da solo, non provoca un ritorno immediato al primo target. I target devono quindi trovarsi dietro il gateway e rappresentare il percorso utile; un ping riuscito non dimostra che DNS, TLS o l’intera applicazione funzionino.

Con Best quality, il failback avviene solo se il gateway originale è migliore di 10 ms per la latenza o di 5 ms per il jitter; per la perdita di pacchetti non esiste un margine equivalente. In Routing > SD-WAN profiles, un profile attivo indica che almeno un gateway è disponibile. Link status riepiloga la configurazione, Historical performance apre le misure e Object usage mostra quali route usano il profile. Controllare questi utilizzi prima di modificarlo o eliminarlo.

Se Route only through specified gateways è attivo, il firewall scarta il traffico quando i percorsi indicati non sono disponibili. Senza questa opzione controlla altre route SD-WAN e poi la default route. Se si elimina un backup gateway, Sophos Firewall lo imposta su None; eliminando il primary gateway o l’SD-WAN profile viene eliminata anche la route e può subentrare la default route.

Con Load balancing e Best quality, il traffico viene distribuito solo se almeno due gateway condividono le migliori prestazioni per il criterio scelto; non tutti i gateway raggiungibili sono idonei. Con Custom SLA, la distribuzione avviene tra i gateway che rispettano le soglie SLA configurate. Un percorso raggiungibile fuori dallo SLA non equivale a un gateway irraggiungibile; questo non stabilisce una regola universale di fallback quando nessun gateway rispetta lo SLA.

Gateway weights descrive un rapporto tra richieste: nell’esempio documentato, 3:1 significa tre richieste su quattro attraverso il primo gateway e una attraverso il secondo. Scegliere i pesi in base alla capacità e alle risorse dei collegamenti; non garantiscono la stessa quota di byte, un throughput specifico o l’aggregazione delle linee.

Per Custom SLA, Maximum latency e Maximum jitter sono espressi in millisecondi e Maximum packet loss in punti percentuali. Interval between checks definisce l’intervallo tra le sonde e Response time-out il tempo di risposta consentito. Deactivate gateway after conta i tentativi di sondaggio consecutivi falliti; Activate gateway after, le risposte consecutive riuscite. Sample size for SLA definisce il numero di campioni delle sonde usati per determinare le prestazioni medie del gateway. Scegliere questi valori per il proprio servizio, senza trasformare un singolo esempio temporale in un valore predefinito universale.

Round-robin distribuisce le richieste in ordine tra i gateway idonei. Con tre gateway disponibili, di uguale peso e senza restrizioni SLA, l’esempio usa il primo, secondo, terzo e poi di nuovo il primo. Session persistence type mantiene le sessioni correlate sullo stesso gateway secondo la chiave scelta, ad esempio per operazioni bancarie o carrelli degli acquisti. Un solo flusso di test non mostra la distribuzione di molte sessioni indipendenti.

Quando nessun gateway rispetta il Custom SLA

Lo scarto per gateway irraggiungibili non dimostra un blocco rigido legato allo SLA per percorsi ancora raggiungibili. Senza prove specifiche della build, non garantire né la prosecuzione di Load balancing né l’uso esclusivo di First available gateway in questo caso.

  1. Documentare build SFOS, profile, Routing strategy, ordine dei gateway, pesi, session persistence, soglie SLA, probe target e Route only through specified gateways.
  2. Usare Link status, Historical performance e log SD-WAN per distinguere percorsi raggiungibili fuori dallo SLA da percorsi realmente irraggiungibili.
  3. Provare solo con un flusso autorizzato e isolato, in una finestra di manutenzione e con accesso di gestione indipendente. Non modificare profile di produzione condivisi per simulare guasti né eliminare gateway o profile. Creare nuove connessioni e verificare gateway, IP SNAT e risultato applicativo con Log Viewer e Packet Capture; valutare separatamente le sessioni esistenti.
  4. Ripristinare i valori di test modificati allo stato iniziale documentato e ripetere controlli di stato e test con traffico reale. Senza prova autorizzata, la selezione resta irrisolta; il chiarimento specifico della build richiede configurazione, misure, timestamp e log, insieme alla build.

Un risultato per una build e un profile non è una garanzia generale di failover.

Coordinare route precedence e NAT

L’ordine predefinito documentato è Static → SD-WAN → VPN. Non è necessariamente lo stato di un’installazione esistente: verificare sempre system route_precedence show prima di decidere e non applicare il default automaticamente.

Route precedence determina l’ordine tra Static, SD-WAN e VPN. Le reti direttamente connesse e SSL VPN appartengono alla categoria Static. L’ordine attuale è visibile in Routing > SD-WAN routes o nella Device Console; modifiche e rollback sono spiegati in Modificare in modo sicuro la route precedence di Sophos Firewall.

Il routing sceglie il percorso, mentre NAT modifica gli indirizzi. Il traffico Internet tramite WAN2 può quindi richiedere MASQ o un IP SNAT fisso su quel percorso. Per reti interne e VPN, invece, NAT è spesso indesiderato. Le relazioni sono spiegate in Capire NAT su Sophos Firewall: SNAT, DNAT, MASQ, PAT.

DNAT verso un server dietro IPsec route-based

Una pubblicazione DNAT pubblica può puntare a un server interno che non è collegato localmente, ma si trova dietro un firewall remoto tramite IPsec route-based. In questo caso particolare, DNAT e la route SD-WAN devono riconoscere lo stesso flusso in entrata prima della traduzione e il percorso di ritorno deve passare di nuovo attraverso il firewall che pubblica il servizio.

Il flusso operativo affidabile per SFOS 22 è composto da cinque parti collegate:

  1. In Hosts and services > IP host, creare un oggetto IP preciso per il server remoto.
  2. In Routing > Gateways, creare un gateway con l’IP del gateway remoto e l’interfaccia XFRM corrispondente. Come destinazione di monitoraggio si usa un host stabile e raggiungibile dietro tale gateway.
  3. Configurare la regola DNAT in modo che corrisponda all’interfaccia WAN pubblica e al servizio offerto esternamente, quindi selezionare il server remoto come Translated destination. L’esempio Sophos usa MASQ affinché le risposte tornino al firewall che pubblica il servizio; tuttavia, il server non vede più l’IP originale del client.
  4. Nella route SD-WAN inserire la stessa interfaccia WAN pubblica in Destination networks e la porta esterna in Services. Con PAT si tratta esplicitamente della porta esterna, non della porta di destinazione interna tradotta. Come primary gateway si seleziona il gateway dell’interfaccia XFRM.
  5. Verificare una regola firewall restrittiva per la pubblicazione e testare il flusso da una rete esterna. NAT Rule ID, Firewall Rule ID, la route SD-WAN, il gateway XFRM selezionato, i percorsi di andata e ritorno e l’IP sorgente visibile sul server devono corrispondere al design.

MASQ non è un’opzione cosmetica. Nell’esempio documentato risolve il percorso di ritorno, ma nasconde al server di destinazione l’IP reale del client. Se il sito remoto dispone di un percorso di ritorno verificato verso le reti client originali e l’IP originale deve essere mantenuto, occorre un design di routing pianificato e testato separatamente. La pubblicazione e la protezione generali sono descritte in Pubblicare un server tramite DNAT su Sophos Firewall.

Più server remoti possono usare la stessa route SD-WAN se sono raggiungibili tramite lo stesso gateway e possono essere distinti chiaramente per indirizzo WAN o porta TCP esterna. Se usano gateway diversi, si configurano route SD-WAN separate. Se corrisponde una porta, un oggetto WAN o un gateway errato, la route non va ampliata a Any; occorre prima dimostrare il flusso pre-DNAT con Log Viewer e Packet Capture.

Testare e approvare la route

Controllare l’elenco delle route e lo stato dei gateway

In Routing > SD-WAN routes si può cercare per nome della route, oggetto o valore dell’oggetto; ad esempio, 443 trova le route che usano il servizio HTTPS. Il trascinamento cambia l’ordine. Si tratta di una modifica al traffico, perché SFOS valuta dall’alto verso il basso e si ferma alla prima corrispondenza.

In More options si può attivare o disattivare una route, modificarla o clonarla, azzerare il contatore dei dati oppure eliminarla. Prima dell’azzeramento annotare valore e ora. Una route clonata è autonoma: controllare nome, criteri, posizione, gateway e NAT prima di salvarla o attivarla, quindi verificarne lo stato On/Off effettivo.

Il tooltip dell’icona nella colonna Active mostra stati come In use, Available, Unavailable, In use, but SLA isn't met o Available and SLA isn't met. La disponibilità di un gateway o profile non dimostra né che questa route sia stata effettivamente selezionata né che il percorso di ritorno funzioni.

Con selezione diretta primary/backup, l’icona Active distingue tre stati: almeno un gateway è raggiungibile e la route è attiva; la route non è attiva e Route only through specified gateways è disattivato; oppure non è attiva e l’opzione è attivata. Nell’ultimo caso, il traffico resta scartato se i percorsi indicati sono irraggiungibili, anziché usare altri gateway. Leggere insieme tooltip e casella di controllo, senza equipararli a uno stato SLA di un profile.

Test standard con traffico reale

  1. Scegliere un client di test con IP noto e una destinazione univoca.
  2. Attivare il logging nella regola firewall corrispondente.
  3. Avviare una connessione reale.
  4. In Log viewer, controllare source, destination, service, rule ID, NAT ID e gateway.
  5. Controllare il traffic count della route SD-WAN: OUT conta le request e IN le reply solo se source e destination corrispondono nella rispettiva direzione.
  6. In System services > Log settings, attivare il tipo SD-WAN e controllare il modulo SD-WAN in Log Viewer per gli eventi di profile, SLA e route.
  7. In caso di dubbi, impostare in Diagnostics > Packet capture un filtro preciso su client, destinazione e porta.

Il Policy tester non considera le route SD-WAN. Può verificare i match delle policy, ma non conferma né la route SD-WAN scelta né il gateway effettivo. Per un’analisi completa, vedere Testare regole Sophos Firewall con Log Viewer, Policy Test e Packet Capture.

Per i log di profile e route nella vista firewall, selezionare il modulo Firewall in Log viewer, aprire la selezione estesa con il pulsante di espansione accanto all’elenco dei moduli, selezionare i log SD-WAN necessari e fare clic su Apply. Questo integra la vista del modulo SD-WAN separato.

Valutare SD-WAN performance

L’asse x dei grafici di qualità mostra il tempo; l’asse y mostra latenza e jitter in millisecondi e perdita di pacchetti in punti percentuali. Assigned weights for load balancing apre i pesi assegnati ai gateway. Misure e pesi non costituiscono l’approvazione dell’applicazione.

In Diagnostics > SD-WAN performance si seleziona il SD-WAN profile utilizzato. In alternativa, si apre Routing > SD-WAN profiles, si seleziona il profile e, in Status, si fa clic su Historical performance. Per ogni gateway, la vista mostra il numero totale di connessioni, i dati trasferiti, i pesi di load balancing assegnati, oltre a latenza, jitter e perdita di pacchetti per Live, 24h, 48h, Week o Month.

Secondo Sophos, No data to display significa che nessuna route utilizza ancora il profile selezionato oppure che non passa traffico attraverso una route di questo tipo. Il messaggio non dimostra quindi un errore di misurazione. Si genera prima un flusso controllato sulla route prevista e lo si conferma con Log Viewer o Packet Capture.

Reset data transfer and connection count modifica i contatori. Prima del reset si documentano valori e orario. Anche un grafico senza anomalie non dimostra ancora che regola firewall, NAT, applicazione e percorso di ritorno funzionino; questi livelli rimangono parte del test reale.

Testare failover e failback in sicurezza

Prima di una modifica annotare la posizione e lo stato On/Off attuali della route, i primary/backup gateway o il profile usato, l’ordine dei gateway nel profile, i valori SLA e Health Check e la traduzione NAT prevista. Il rollback consiste nel ripristinare esattamente tali valori e poi ricontrollare stato, log e traffico reale.

Un test di guasto controllato si esegue durante una finestra di manutenzione, con rollback documentato e un percorso di gestione indipendente verso il firewall. Prima si controllano nella Device Console gli attuali valori di stato in sola lettura:

system route_precedence show
show routing reroute-connection
show routing reroute-snat-connection

Successivamente si avvia traffico applicativo reale, si rende indisponibile in modo controllato il primary gateway e si verificano percorso, sessioni, Public Source IP e ritorno. Per questo test non si devono eliminare primary gateway o SD-WAN profile, perché ciò rimuove la route e verifica solo il fallback sulla default route. Anche la modifica della route o del profile e un cambiamento della Route Precedence possono instradare nuovamente le connessioni esistenti e non devono far parte dello stesso test di riferimento. Con selezione diretta primary/backup, le nuove connessioni tornano al primary quando rientra; quelle esistenti restano generalmente sul backup gateway.

reroute-connection è attivo per impostazione predefinita e riguarda connessioni senza SNAT. Le connessioni SNAT non vengono reindirizzate per impostazione predefinita; anche con reroute-snat-connection attivato separatamente, funziona solo se entrambi i percorsi usano lo stesso Source IP tradotto. Con MASQ o indirizzi Override Source Translation diversi, la connessione SNAT non viene reindirizzata e la sessione esistente si interrompe quando il percorso cade.

Modificare consapevolmente il rerouting

Queste impostazioni modificano il traffico; non sono prerequisiti del test di riferimento. Modificarle solo in una finestra di manutenzione con accesso di gestione indipendente verificato e rollback documentato: salvare prima i due stati di rerouting mostrati sopra e verificare che i due percorsi usino lo stesso Source IP tradotto per SNAT. In Device Console sono disponibili le seguenti alternative; eseguire solo il comando necessario alla modifica prevista, non tutti in sequenza:

  • Attivare senza SNAT: set routing reroute-connection enable; disattivare: set routing reroute-connection disable.
  • Attivare per SNAT: set routing reroute-snat-connection enable; disattivare: set routing reroute-snat-connection disable.

Poi verificare con show routing reroute-connection e show routing reroute-snat-connection e testare separatamente sessioni, Source IP e entrambe le direzioni del traffico. Per il rollback, ripristinare ogni impostazione modificata nello stato enable/disable registrato e ripetere i controlli di stato e traffico reale. Attivare il rerouting SNAT non elimina i limiti MASQ/IP.

Individuare i problemi in modo sistematico

La route non corrisponde

  • Confrontare incoming interface, source network, destination e service con il flusso reale.
  • Controllare l’ordine; vince la prima route SD-WAN corrispondente.
  • Per gli Application Objects, verificare licenza, riconoscimento DPI e una seconda connessione dopo la classificazione.
  • Non usare il traffic count come unica prova, perché request e reply vengono contate solo con criteri source/destination corrispondenti.
  • Con Direct Web Proxy non basta un service HTTP/HTTPS: usare Any o un service per la porta configurata in Web > General settings > Web proxy listening port. In questo caso speciale, source network e incoming interface non corrispondono per i reply packet; il ritorno del proxy richiede inoltre un WAN default gateway o una route statica adeguata.
  • Per una route SD-WAN migrata da SFOS 17.5 o precedente, verificare se è stata eliminata la regola firewall originale. Queste route migrate restano collegate alla vecchia regola e vengono eliminate insieme ad essa.
  • Per IPv6, Dead Gateway Detection nelle route SD-WAN non monitora traffico di rete di terze parti come SNMP. L’assenza di una misurazione esterna non è quindi una prova affidabile dello stato DGD.

Configurare Direct Web Proxy con un file PAC descrive listener, distribuzione ai client, regola di protezione e test con traffico reale.

Per reply packet e system-generated traffic si applicano switch e regole di corrispondenza separati. Questi casi sono spiegati in Verificare il routing SD-WAN Sophos Firewall per reply packets e system traffic.

Web Admin e SSH non sono raggiungibili dopo una nuova route

Uno scenario documentato combina quattro impostazioni: SD-WAN precede Static, una nuova route per una rete sorgente interna specifica ha destination Any, il routing SD-WAN per il traffico generato dal sistema è attivo e lo è anche per i reply packet. L’accesso di gestione dalla rete interna interessata può quindi interrompersi, restando disponibile da altre sottoreti. Non sono condizioni necessarie per ogni interruzione della gestione.

Tramite un accesso alternativo già verificato, controllare sorgente, destinazione e precedenza della route, insieme a questi valori in sola lettura nella Device Console:

show routing sd-wan-policy-route system-generate-traffic
show routing sd-wan-policy-route reply-packet

Verificare prima che la gestione da una sottorete non interessata sia effettivamente consentita e raggiungibile. Quindi limitare in modo mirato la destinazione oppure ripristinare una delle impostazioni precedentemente modificate al valore originale documentato. Non eseguire un reset globale alla cieca: salvare prima posizione, impostazioni e precedenza, pianificare il rollback e ricontrollare Web Admin, SSH e il traffico interessato. Senza un accesso alternativo sicuro, non proseguire la modifica da remoto.

Il traffico prende il percorso sbagliato

  • Per destinazioni IPv4 pubbliche, sostituire Any con Internet IPv4 group o destinazioni specifiche.
  • Controllare route precedence, soprattutto se sono interessate reti interne, SSL VPN o IPsec policy-based.
  • Controllare lo stato di gateway e SLA e gli Health Check Targets.
  • Confrontare la regola NAT e il Source IP tradotto con il gateway effettivamente utilizzato.
  • Verificare se un primary gateway o SD-WAN profile è stato eliminato, rimuovendo anche la route.

L’applicazione o la risposta non funziona dopo il failover

Per prima cosa, con Packet Capture verificare se il pacchetto esce dal gateway previsto e se la risposta torna. Controllare poi NAT, allowlist di IP pubblici, Session Persistence, MTU/MSS e lo stato del percorso VPN o MPLS. SIP/RTP, portali bancari e API con Source IP fisso devono essere testati soprattutto con traffico applicativo reale.

Se il problema è iniziato subito dopo l’upgrade a SFOS 22.0 GA, verificare innanzitutto la build installata. SFOS 22.0 MR1 Build 490 corregge NC-173667, che causava la disconnessione casuale di una route SD-WAN, e NC-177603, per cui l’audio VoIP tramite una VPN route-based funzionava in una sola direzione dopo l’upgrade a 22.0 GA. Se è già installata MR1 o una build successiva, non attribuire il guasto soltanto alla versione firmware; ripetere il test con traffico reale descritto sopra e verificare route, sessioni, NAT e traffico in entrambe le direzioni.

API XML: chiarire i confini degli oggetti prima dell’automazione

La documentazione dell’API XML per SFOS 22.0 e 23.0 descrive oggetti denominati distinti. La configurazione tramite UI spiegata sopra rimane la procedura pratica; da essa, tuttavia, non si può ricavare un contratto XML univoco. Chiarire le contraddizioni seguenti nell’API help della build installata prima di costruire la richiesta. Per l’automazione è necessario che Sophos chiarisca i campi interessati per la versione specifica; qui non si ipotizza alcuna mappatura numerica né si fornisce una richiesta XML eseguibile.

HealthCheckProfile denominato: ciclo di vita e contatori delle sonde

HealthCheckProfile è un oggetto Health Check autonomo, non è lo SDWANProfile né l’opzione integrata di controllo dello stato del gateway. Durante la creazione e l’aggiornamento, il campo stringa scalare obbligatorio Name identifica il profilo Health Check; entrambe le tabelle dei campi indicano un massimo di 125 caratteri. La tabella della versione 22.0 vieta inoltre le virgole e consente esplicitamente i caratteri UTF-8, mentre queste due indicazioni mancano nella tabella della versione 23.0. Tale assenza non dimostra una modifica della validazione del nome.

ProbeTargets è descritto come un array di oggetti monitorDetails, mentre nell’esempio compaiono elementi ProbeTarget. monitormethod indica TCP o PING; monitorip indica i tipi di dati IPADDRESS, IPADDRESS6 e DOMAINNAMELOOKUP. Per operator sono riportati i valori letterali & e |, con valore predefinito |. Da queste informazioni non si deduce né una struttura XML diversa né un’equivalenza con il comportamento dei due Probe Targets nella UI descritto sopra. Anche IPFamily rimane contraddittorio: entrambe le tabelle indicano IPv4 e IPv6, con valore predefinito IPv4, ma allo stesso tempo un massimo di 1 carattere.

Le due righe dei contatori sembrano invertite rispetto ai rispettivi nomi: ProbesResponseFailure descrive letteralmente risposte consecutive per l’attivazione dell’oggetto, con valore predefinito 1; ProbeResponseSuccess descrive sonde consecutive senza risposta prima della sua disattivazione, con valore predefinito 3. Entrambe le tabelle indicano per ciascun campo l’intervallo da 1 a 10. Questa associazione documentale non viene corretta tacitamente e non conferma il comportamento in esecuzione. In particolare, le spiegazioni affidabili della UI relative a Deactivate gateway after e Activate gateway after non vengono trasferite automaticamente a questi tag API.

Anche l’operazione di eliminazione separata identifica il profilo Health Check tramite Name, non una route o un SD-WAN profile. Prima di un’eliminazione prevista, si verificano gli SD-WAN profile che lo referenziano e si documenta la loro attuale associazione Health Check. Le fonti non attestano una sequenza a cascata sicura né il comportamento in caso di eliminazione di un oggetto Health Check ancora referenziato. Questa operazione non equivale all’eliminazione di un SD-WAN profile descritta sopra; inoltre, tale eliminazione non è un test di guasto.

HealthCheckProfileStatus: stato amministrativo dell’oggetto Health Check

HealthCheckProfileStatus attiva o disattiva amministrativamente il profilo Health Check denominato. Il selettore è il campo stringa scalare obbligatorio Name; il segnaposto dell’esempio HealthCheckProfileStatusName non modifica l’identità di questo campo. In entrambe le versioni, l’esempio riporta ON/OFF per Status, mentre la riga del campo obbligatorio indica INTEGER senza associazione numerica. Non è quindi attestata una forma numerica per l’attivazione o la disattivazione. Questa amministrazione non coincide con la disponibilità misurata del gateway, con lo stato attivo di un SD-WAN profile o con l’attivazione e la disattivazione di una route. Un messaggio di successo documentato, da solo, non dimostra che lo stato sia effettivamente cambiato; occorrerebbe verificare lo stato amministrativo di quello specifico oggetto denominato, separatamente dagli indicatori di disponibilità.

SDWANPolicyRouteStatus: verificare la route corretta e lo stato corretto

SDWANPolicyRouteStatus utilizza come selettore stringa scalare obbligatorio SDWANPolicyRouteName, non il campo Name di un profilo Health Check. Gli esempi di entrambe le versioni mostrano nuovamente ON/OFF per Status, mentre la riga del campo obbligatorio indica INTEGER e non fornisce alcuna mappatura numerica. Il codice di risultato documentato 200 non costituisce una conferma indipendente che la route desiderata abbia cambiato stato amministrativo. A tale scopo occorrerebbe verificare lo stato On/Off effettivo di questa route. Il tooltip Active, la raggiungibilità del gateway e la decisione di scarto o fallback determinata da Route only through specified gateways rispondono ad altre domande e non risolvono il contratto XML contraddittorio relativo allo stato.

SDWANProfile: famiglia, strategia e riferimento Health Check separato

In SDWANProfile, Name identifica lo stesso SD-WAN profile, con un massimo di 60 caratteri. Il campo stringa scalare obbligatorio HealthCheckProfileName è invece il riferimento al profilo Health Check separato, con un massimo di 85 caratteri. Non si tratta della stessa identità né della stessa lunghezza del nome documentata per il suo campo Name, pari a 125 caratteri. I confini dell’oggetto e dei contatori di HealthCheckProfile si applicano quindi anche alla preparazione di questo riferimento; le impostazioni Health Check integrate non sostituiscono il riferimento denominato richiesto.

Entrambi gli esempi dei profili e le descrizioni dei campi riportano IPv4/IPv6 per IPFamily, ma la riga di validazione consente solo IPv4 e indica allo stesso tempo un massimo di 1 carattere. Le route IPv6 nella UI non attestano quindi il supporto IPv6 di questo contratto XML del profilo. Per SLAStrategy, l’esempio e la descrizione riportano BestQuality, mentre l’elenco dei valori consentiti riporta BestQualityv; CustomSLA compare in entrambi. Per LBMethod, l’esempio indica WRR/SrcSticky/DestSticky/SrcDestSticky/ConnectionSticky, mentre la tabella indica INTEGER nell’intervallo da 0 a 5 senza associazione a questi valori testuali. Per IsLatency, il valore predefinito 1 contrasta con i valori letterali consentiti OFF e ON. Nessuna di queste differenze viene risolta ipotizzando una correzione ortografica, una forma numerica o una mappatura booleana dedotta. Le strategie e le procedure di verifica della UI descritte sopra rimangono utilizzabili, ma non dimostrano la validità di una richiesta eseguibile per il profilo.

Gestione e documentazione

Per ogni route SD-WAN in produzione si documentano scopo, incoming interface, source/destination, services, gateway o profile, fallback, comportamento NAT previsto, client di test, destinazione di test, owner e data di revisione. Dopo modifiche a provider, VPN, interfacce o servizi cloud si verificano nuovamente match, log e failover.

Una route è approvata solo quando:

  • i criteri di corrispondenza includono solo il traffico previsto
  • regola firewall, NAT e route precedence corrispondono al design
  • Log Viewer e Packet Capture confermano il percorso previsto
  • failover, failback e Public Source IP si comportano come documentato
  • sono registrati un responsabile e la prossima data di revisione