Vai al contenuto
Avanet

Sophos Firewall SD-WAN Controllare l'instradamento per Reply Packets e System Traffic

SD-WAN I percorsi su Sophos Firewall non sono rilevanti solo per il classico traffico da client a Internet. A seconda dell’ambiente, potrebbero essere interessati anche Reply Packets e il traffico generato dal sistema. Proprio qui sorgono spesso problemi di routing difficili da riconoscere: la regola sembra corretta, il Gateway è attivo ma le risposte passano per la strada sbagliata oppure il firewall stesso non raggiunge un servizio attraverso la linea prevista.

Questa guida spiega le due opzioni CLI reply-packet e system-generate-traffic, quando selezionarle e come testare in sicurezza le modifiche. Per la normale configurazione del percorso SD-WAN, Configura e testa il percorso e prova Sophos Firewall SD-WAN si adatta per primo. Per l’ordine generale tra route statiche, route policy SD-WAN e route VPN, è adatto anche Sophos Firewall modifica sicura Route Precedence.

⚠️ Queste impostazioni possono influenzare immediatamente il routing produttivo. Prima di apportare una modifica, dovresti documentare lo stato attuale, scegliere una finestra di manutenzione e conoscere un modo chiaro per tornare indietro. Particolarmente critici sono gli ampi percorsi SD-WAN con Any, Route Precedence davanti a percorsi statici e il routing SD-WAN attivato per System Traffic o Reply Packets.

Cosa riguardano le due opzioni

Con i percorsi SD-WAN devi distinguere tra il normale traffico inoltrato, i pacchetti di risposta e il traffico generato dal firewall stesso. Le due opzioni non determinano se una singola route SD-WAN è creata correttamente. Invece, espandono il tipo di traffico che può essere preso in considerazione dal routing delle policy SD-WAN.

Le due opzioni hanno compiti diversi:

  • reply-packet: Influisce sui pacchetti di risposta al traffico esistente. Ciò consente di influenzare il percorso di ritorno tramite SD-WAN in alcuni scenari non WAN.
  • system-generate-traffic: Influisce sul traffico generato dal firewall stesso. Ciò consente di instradare le connessioni specifiche del firewall tramite percorsi SD-WAN definiti.

Entrambe le opzioni non dovrebbero essere attivate alla cieca solo perché “SD-WAN non funziona”. Innanzitutto deve essere chiaro se il traffico Reply Packets o quello generato dal sistema è realmente interessato. Per le connessioni normali, la vera causa è spesso la regola del firewall, lo stato NAT, Route Precedence, Gateway o un percorso SD-WAN troppo ampio.

Reply Packets

Reply Packets sono pacchetti di risposta al traffico esistente. Sophos Firewall generalmente applica un routing simmetrico per tali risposte sulle interfacce WAN: i pacchetti di risposta dovrebbero ritornare sulla stessa interfaccia WAN attraverso la quale è arrivata la connessione originale. L’opzione reply-packet è particolarmente rilevante se i pacchetti di risposta devono essere presi in considerazione in determinati scenari di policy routing SD-WAN. Un tipico esempio è il routing asimmetrico su interfacce non WAN, come tra LAN e DMZ.

La limitazione importante è: se il traffico originale viene eseguito tramite il percorso predefinito o il bilanciamento del carico del collegamento WAN, i percorsi SD-WAN non si applicano a questo Reply Packets. Il firewall continua quindi a utilizzare il percorso di ritorno appropriato tramite l’interfaccia della connessione originaria.

Domande tipiche del test:

  • Si tratta davvero di traffico di risposta e non di una nuova connessione?
  • Il traffico passa attraverso WAN, LAN, DMZ, XFRM o un’altra zona?
  • Esiste un percorso SD-WAN destinato a influenzare intenzionalmente il percorso di ritorno?
  • Il percorso è troppo largo, ad esempio destinazione Any?
  • Route Precedence ha effetto prima di una route statica o di una route VPN?

Traffico generato dal sistema

Il traffico generato dal sistema è il traffico che il Sophos Firewall genera da solo. A seconda dell’ambiente, ciò può includere DNS, NTP, Sophos Central, Syslog, aggiornamenti, monitoraggio, servizi di autenticazione o connessioni diagnostiche.

Con questo traffico il firewall non riconosce una normale interfaccia in entrata e una normale rete di origine come nel caso del traffico client inoltrato. Per questo motivo è necessario pianificare con particolare attenzione i percorsi SD-WAN per il traffico generato dal sistema: le reti di destinazione e Services devono essere scelte in modo sensato. Un percorso molto ampio potrebbe altrimenti trascinare inaspettatamente il traffico di gestione o di sistema su un percorso sbagliato.

Inoltre si applicano due limiti pratici:

  • Se tutti i gateway configurati in Network > WAN link manager sono contrassegnati solo come Backup, il firewall non inoltrerà il traffico generato dal sistema attraverso di essi. Almeno un Gateway deve essere Attivo.
  • Il traffico RED generato dal sistema su UDP 3410 è traffico di livello 2. SD-WAN I percorsi non si applicano a questo.

Quando controllare queste impostazioni

Le due opzioni sono particolarmente rilevanti per progetti di routing più complessi. In semplici ambienti WAN singoli raramente sono la prima leva.

Trigger utili:

  • Il traffico nativo del firewall non utilizza il percorso WAN o VPN previsto.
  • Syslog, Centrale, DNS, NTP o monitoraggio dovrebbero essere eseguiti su una linea specifica.
  • IPsec VPN basato su percorsi con interfacce XFRM viene utilizzato insieme ai percorsi SD-WAN.
  • VoIP o altro traffico sensibile funziona solo in una direzione tramite SD-WAN/VPN.
  • Packet Capture mostra le risposte su un’interfaccia diversa dal previsto.
  • Dopo un aggiornamento, SD-WAN, IPsec o NAT si comportano diversamente rispetto a prima.
  • Un ampio percorso SD-WAN influisce improvvisamente sulle reti interne o sull’accesso alla gestione. Per gli scenari IPsec dovresti includere anche Risoluzione dei problemi Sophos Firewall IPsec VPN. Per le singole connessioni, Test delle regole Sophos Firewall con Log Viewer e Packet Capture è spesso un punto di partenza migliore.

Visualizza lo stato attuale

I comandi vengono eseguiti in Device Console, non in Advanced Shell. Se l’accesso alla console non è ancora chiaro, Connetti Sophos Firewall tramite SSH sarà di aiuto.

Controlla lo stato per Reply Packets:

show routing sd-wan-policy-route reply-packet

Controlla lo stato del traffico generato dal sistema:

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

Inoltre, WebAdmin sotto Routing > SD-WAN routes mostra nella descrizione comando delle informazioni di routing se il routing SD-WAN è attivo per il traffico generato dal sistema e Reply Packets.

Prima di apportare qualsiasi modifica, è necessario documentare l’edizione corrente. Questo è importante perché un successivo rollback è possibile in modo pulito solo se lo stato precedente è noto.

Abilita le opzioni

SD-WAN Attiva l’instradamento per Reply Packets:

set routing sd-wan-policy-route reply-packet enable

SD-WAN Abilita l’instradamento per il traffico generato dal sistema:

set routing sd-wan-policy-route system-generate-traffic enable

Quindi eseguire nuovamente i comandi di stato e documentare l’output.

⚠️ Non apportare più modifiche al percorso contemporaneamente. Se Route Precedence, percorso SD-WAN, regola NAT e queste opzioni CLI vengono modificate contemporaneamente, è difficile attribuire chiaramente un errore in seguito.

Flusso sicuro per le modifiche

Un processo pragmatico riduce il rischio:

  1. Definire in modo specifico il traffico interessato: Sorgente, Destinazione, Servizio, Zona, previsto Gateway.
  2. Documentare i percorsi SD-WAN esistenti, i gateway e Route Precedence.
  3. Verificare se la Destinazione Any è realmente necessaria.
  4. Documentare lo stato attuale di reply-packet e system-generate-traffic.
  5. Cambia solo un’opzione.
  6. Esegui il test con un chiaro esempio di traffico.
  7. Controllare i contatori Log Viewer, Packet Capture e Gateway.
  8. Documentare il risultato e solo successivamente apportare ulteriori modifiche. Se l’accesso di gestione potrebbe essere interessato, dovrebbe essere disponibile un mezzo di accesso secondario: console locale, altro percorso di accesso interno o accesso da una rete di gestione non interessata.

Convalida dopo la modifica

Dopo l’attivazione, lo stato verde Gateway non è sufficiente. Devi verificare se il traffico desiderato segue davvero il percorso previsto.

Registri Log Viewer e SD-WAN

Gli eventi relativi al firewall e a SD-WAN devono essere controllati nel Visualizzatore registro. Per le regole firewall pertinenti, Log firewall traffic deve essere attivo. Senza effettuare la registrazione, spesso vedi solo una parte della decisione.

Per verificare:

  • Quale Firewall Rule ID viene colpito?
  • Quale NAT Rule ID viene utilizzato?
  • Quale Gateway o quale interfaccia appare nel registro?
  • Ci sono cadute, violazioni delle policy o decisioni inaspettate sulle funzionalità di sicurezza?

Packet Capture

Il flusso effettivo dei pacchetti può essere controllato con Diagnostics > Cattura pacchetti. Per le domande sul routing, il filtro dovrebbe essere ristretto: Origine IP, Destinazione IP, Porta e Protocollo.

Il confronto è importante:

  • Il pacco arriva all’interfaccia prevista?
  • Esce dal firewall sull’interfaccia prevista?
  • Arriverà la risposta?
  • Viene utilizzato NAT?
  • Il percorso di ritorno è plausibile per Reply Packets?

Utilizzare Sophos Firewall Packet Capture in WebAdmin è adatto per il funzionamento e l’interpretazione.

Controlla i servizi di sistema

Nel caso del traffico generato dal sistema, dovresti testare specificamente il servizio interessato:

  • DNS: esegui la ricerca DNS sul firewall e controlla il percorso di destinazione.
  • NTP: Controlla lo stato temporale e la disponibilità del server NTP.
  • Syslog: Controlla il messaggio di prova o il registro corrente sul raccoglitore.
  • Sophos Central: Controllare la connessione centrale e il reporting.
  • Monitoraggio: Controllare SNMP, sFlow o controlli esterni sul collettore.

Se il traffico generato dal sistema non è visibile, dovresti anche verificare se il percorso SD-WAN deve corrispondere solo alle reti di origine o alle interfacce in entrata. Questi criteri non sono disponibili per il traffico di proprietà del firewall come lo sono per il traffico client.

Errori tipici

  • Instradamento SD-WAN con destinazione Any per percorsi interni: Il traffico interno o l’accesso di gestione possono essere instradati tramite WAN. Sono preferibili gruppi target su Internet o reti target specifiche.
  • Route Precedence imposta SD-WAN prima di Statico: Le reti connesse direttamente o statiche potrebbero essere inaspettatamente abbinate a SD-WAN. Controllare Route Precedence e impostare Statico davanti a SD-WAN se necessario.
  • system-generate-traffic attivo senza limitazione di destinazione: i servizi specifici del firewall possono utilizzare il percorso sbagliato. Pertanto, definire attentamente le reti di destinazione e Services.
  • Reply Packets confuso con nuove connessioni normali: Quindi viene elaborata la causa sbagliata. Packet Capture e controllare la direzione del flusso.
  • Diversi cambiamenti di routing contemporaneamente: La causa dell’errore non è chiara. Cambia gradualmente e documenta ogni test.
  • Nessun accesso di gestione alternativo: WebAdmin o SSH potrebbero andare persi dalla rete interessata. Preparare la finestra di manutenzione e il percorso di accesso.

Un rischio particolarmente critico sorge quando si verificano diverse condizioni: Route Precedence si trova su SD-WAN prima di statico, un ampio percorso SD-WAN utilizza Any e il routing SD-WAN per il traffico generato dal sistema o Reply Packets è attivo. In questo caso, l’accesso a WebAdmin o SSH da alcune sottoreti interne potrebbe andare perso.

Interazione con NAT, IPsec e VoIP

SD-WAN è raramente coinvolto da solo. NAT, IPsec o il traffico specifico dell’applicazione svolgono un ruolo in molte interruzioni. Ciò che è importante per SNAT è se la stessa origine IP viene mantenuta su gateway diversi. Se vengono utilizzati MASQ o indirizzi di origine tradotti diversi, il failover o il reindirizzamento potrebbero causare problemi di comunicazione. Per le nozioni di base, Comprendere che NAT si adatta a Sophos Firewall.

Per le VPN IPsec basate su percorso, le interfacce XFRM possono essere utilizzate nei percorsi SD-WAN o nei profili SD-WAN. Quindi lo stato IPsec, il percorso SD-WAN, Route Precedence e le regole del firewall devono essere controllati insieme. Le basi VPN basate su percorso sono classificate in Percorso IPsec su Sophos Firewall. Se hai problemi VoIP, vale la pena dare un’occhiata anche a SIP, RTP, NAT e SD-WAN. Le note di rilascio di SFOS-22.0-MR1 documentano un problema risolto per cui l’audio VoIP funzionava solo in una direzione tramite VPN basato su routing con routing SD-WAN dopo l’aggiornamento a SFOS 22.0 GA. Il processo pratico è disponibile in Sophos Firewall Risolvere i problemi VoIP con SIP e RTP.

Ritorno indietro

Prima di apportare modifiche, è necessario documentare il vecchio stato. Se poi vengono colpiti gli accessi gestionali, i servizi di sistema o il traffico produttivo, l’improvvisazione non è più necessaria. Per prima cosa ripristina lo stato precedente.

In pratica questo significa:

  1. Reimpostare i valori documentati prima per reply-packet e system-generate-traffic.
  2. Se modificato, riportare Route Precedence all’ordine precedente.
  3. Disattiva temporaneamente i percorsi SD-WAN troppo ampi o limitali a destinazioni specifiche.
  4. Testare l’accesso alla gestione da una rete non interessata.
  5. Quindi restringere ulteriormente la causa effettiva.

Se l’accesso a WebAdmin e SSH viene perso da una sottorete interna ma è ancora possibile da un’altra sottorete, è necessario controllare prima il percorso SD-WAN ampio, Route Precedence e le due opzioni CLI da lì.

Lista di controllo

  • Stato attuale delle due opzioni CLI documentato.
  • Traffico interessato specificamente definito.
  • Il percorso SD-WAN non è stato costruito inutilmente largo con Any.
  • Route Precedence controllato.
  • Almeno un WAN-Gateway per System Traffic disponibile come Attivo.
  • Predisposizione connessione gestione alternativa.
  • Effettuata una sola modifica per test.
  • Log Viewer e Packet Capture utilizzati per la convalida.
  • NAT, IPsec e regole firewall controllate.
  • Risultato e rollback documentati nel giornale delle operazioni.

Domande frequenti

Devi sempre attivare il pacchetto di risposta e il traffico generato dal sistema?

No. Le opzioni hanno senso solo se Reply Packets o il traffico generato dal sistema devono essere realmente controllati tramite percorsi SD-WAN. In ambienti semplici possono creare complessità inutili.

Perché un percorso SD-WAN può interferire con l'accesso a WebAdmin o SSH?

Se un ampio instradamento SD-WAN con Any ha la precedenza sugli instradamenti statici e viene preso in considerazione anche il traffico generato dal sistema o Reply Packets da SD-WAN, il traffico di gestione da una sottorete interna può passare sul percorso sbagliato.

Il tester delle policy SD-WAN mostra il routing correttamente?

No. Il tester delle policy è utile per la logica delle policy firewall, web e SSL/TLS, ma non sostituisce un test reale del flusso di pacchetti. Per SD-WAN dovresti usare Log Viewer e Packet Capture.

Perché un percorso SD-WAN vede solo i contatori di richieste o risposte?

SD-WAN I percorsi conteggiano solo il traffico che corrisponde ai criteri di origine e destinazione del percorso. A seconda della direzione, nel contatore può essere visibile solo il traffico di richiesta o di risposta.