Scegliere la modalità operativa corretta di Sophos RED

La modalità operativa di una Sophos SD-RED non è un’opzione secondaria. Stabilisce chi fornisce DHCP e gateway nella sede remota, quale traffico attraversa il tunnel RED, se l’accesso a internet viene controllato centralmente e cosa continua a funzionare quando il tunnel si interrompe. Un tunnel Site-to-Site RED tra due Sophos Firewall è un’altra architettura e non utilizza queste quattro modalità operative.

Per le nuove filiali gestite centralmente, Standard/Unified è in genere il punto di partenza più chiaro. Standard/Split riduce il traffico nel tunnel, ma sottrae il traffico internet locale al controllo centrale. Transparent/Split integra la RED in una rete esistente. Manual/Split è uno speciale progetto di cablaggio e routing per mantenere l’autonomia internet locale, non una semplice modalità rapida.

La modalità operativa va scelta prima di configurare DHCP, VLAN, regole firewall e rollout. Una modifica successiva cambia il percorso dei dati e richiede una finestra di manutenzione con test funzionali controllati.

Questa guida riguarda SFOS 22.0 e i modelli SD-RED 20 e SD-RED 60 supportati da questa versione. RED 15/15w e RED 50 non si connettono più a partire da SFOS 20.0 MR1. Le interfacce Firewall RED legacy tra UTM e SFOS devono essere sostituite ed eliminate prima dell’aggiornamento a SFOS 22.0; altrimenti upgrade, ripristino e importazione vengono bloccati. Da SFOS 21.0 MR2 e 21.5 MR1, agli host di sistema RED viene assegnata automaticamente una maschera /32. In Hosts and services > IP host, aprire Usage per ogni host di sistema RED e, dove prima si intendeva l’intera subnet dell’interfaccia, sostituirlo nelle regole e rotte dipendenti con l’host IP o di rete corretto. Questi controlli di migrazione devono quindi rientrare nel piano di modifica prima di una migrazione hardware o del firewall.

Le spiegazioni relative alle modalità operative, alle modalità delle porte LAN e ai percorsi dei dati WLAN si applicano a SFOS 22.0 e 23.0. Le indicazioni per la migrazione nel paragrafo precedente restano vincolate alle release espressamente indicate in quel paragrafo. Prima di cambiare modalità in produzione, il comportamento deve essere verificato in condizioni controllate sul modello e sulla release in uso.

Le quattro modalità RED in sintesi

Questa sintesi aiuta nella prima scelta, ma non sostituisce la verifica del comportamento in caso di guasto, delle VLAN e della sicurezza. In particolare, Split non significa automaticamente fail-open e Transparent non significa automaticamente che i tag VLAN vengano inoltrati.

Standard/Unified: Tutto attraverso la sede centrale

In Standard/Unified, Sophos Firewall fornisce DHCP e gateway predefinito tramite l’interfaccia RED. La SD-RED inoltra tutto il traffico nel tunnel cifrato, compreso il traffico internet della filiale.

Questa modalità offre il massimo controllo centrale. Regole firewall, Web Policy, IPS, Application Control, reporting e accesso internet centrale possono essere applicati in modo coerente nella sede principale. Allo stesso tempo aumentano i requisiti del tunnel e della connessione WAN centrale, perché anche il normale traffico internet della filiale percorre due volte il collegamento tra le sedi.

Se il tunnel RED si interrompe, i client non perdono soltanto l’accesso alle reti interne. Poiché il loro gateway si trova su Sophos Firewall oltre il tunnel, normalmente viene meno anche l’accesso a internet. Standard/Unified è quindi adatto quando la sicurezza centrale è più importante del funzionamento dell’internet locale durante un guasto del tunnel.

Quando è adatto Standard/Unified

• Tutto il traffico della sede deve essere controllato e registrato centralmente.
• DHCP, inoltro DNS, regole e accesso a internet devono convergere su Sophos Firewall.
• La capacità WAN centrale è sufficiente per il traffico internet aggiuntivo della filiale.
• Un guasto del tunnel può mettere intenzionalmente offline la sede oppure è disponibile un secondo uplink RED già testato.
• Le VLAN devono essere trasportate attraverso una SD-RED 60.

Standard/Split: Reti centrali attraverso il tunnel

Con Standard/Split, Sophos Firewall rimane il server DHCP e il gateway predefinito della rete fornita dalla RED. Solo le reti di destinazione inserite in Split networks attraversano il tunnel. Le altre destinazioni, in genere internet, escono dalla sede tramite la connessione WAN locale della RED.

Questo riduce il carico del tunnel e della connessione internet centrale. Il compromesso è un limite di sicurezza chiaro: Sophos maschera il traffico internet locale sulla RED, ma il firewall centrale non può controllarlo con le proprie regole firewall, web o IPS. Dal punto di vista della sede centrale, questo percorso non è un normale traffico internet inoltrato.

In Split networks si usano reti IP. Gli oggetti host FQDN non sono supportati in questo punto. Anche i frame già taggati con VLAN non appartengono al percorso dati di Standard/Split. Solo la rete DHCP fornita direttamente dalla RED ottiene l’accesso internet locale tramite questa modalità.

Un esempio per Split network: La filiale utilizza 10.20.30.0/24, mentre la rete di server necessaria della sede centrale utilizza 10.10.40.0/24. Solo la rete di destinazione centrale viene inserita come rete split; non è né l’intervallo DHCP della filiale né un host FQDN. Queste reti private sono esempi e devono essere sostituite con le proprie reti non sovrapposte. Successivamente vengono testati separatamente un server in questa rete, una destinazione locale esterna all’elenco e una destinazione Internet. Le risorse interne non elencate non diventano automaticamente raggiungibili tramite la sede centrale: seguono il percorso locale rimanente.

Standard/Split non è nemmeno un progetto fail-open generale. Se il tunnel si interrompe, la documentazione Sophos indica che i client della rete fornita dal firewall perdono sia le destinazioni centrali sia l’accesso a internet. Se l’accesso internet locale deve funzionare indipendentemente dal tunnel, è necessario progettare e testare una soluzione diversa.

Quando è adatto Standard/Split

• La filiale necessita solo di poche reti chiaramente definite nella sede centrale.
• Il breakout internet locale è intenzionale e può restare fuori dalle policy Sophos centrali.
• Sophos Firewall può amministrare la rete remota tramite DHCP.
• Non è necessario trasportare tag VLAN nel tunnel RED.
• Il percorso in caso di guasto è stato testato e non viene confuso con Manual/Split.

Transparent/Split: RED nella rete esistente

Transparent/Split è adatto alle sedi remote in cui router, DHCP, DNS e gateway predefinito esistono già e devono rimanere invariati. La RED opera in modo trasparente nella rete Layer 2 esistente. Solo le reti o i domini split configurati vengono indirizzati nel tunnel verso la sede centrale.

Questa modalità evita di cambiare il gateway dei client. La risoluzione dei problemi diventa però più impegnativa: DHCP, DNS e il normale percorso internet restano nella rete locale, mentre alcune destinazioni vengono deviate attraverso la RED. I test devono quindi dimostrare separatamente quale percorso rimane locale e quale entra realmente nel tunnel.

Per i nomi interni, Transparent/Split richiede inoltre un Split DNS server, ossia un server DNS nella rete centrale che i client remoti possano interrogare per il dominio interno interessato. Un dominio split non è la stessa cosa di un host FQDN in Split network. Ad esempio, per corp.example, la risoluzione tramite il server DNS interno previsto deve funzionare e la sua rete deve essere raggiungibile attraverso il tunnel. corp.example è un segnaposto per il proprio dominio interno. Se l’IP del server è raggiungibile ma il nome no, verificare prima la risposta DNS effettiva, il resolver utilizzato e il percorso verso tale resolver; non ampliare indiscriminatamente la regola del firewall.

Transparent/Split non trasporta frame taggati con VLAN. In questa modalità non è disponibile nemmeno un uplink di failover 3G/4G. Per un modulo wireless, il server DHCP remoto deve trasmettere all’access point l’opzione DHCP 234 con l’indirizzo IP dell’interfaccia RED nella sede del firewall; non si tratta dell’indirizzo dell’AP, di un indirizzo della filiale o dell’indirizzo pubblico del firewall.

Quando è adatto Transparent/Split

• Il router esistente deve continuare a fornire DHCP, DNS e gateway predefinito.
• Solo reti o domini centrali selezionati devono essere raggiungibili tramite la RED.
• La RED può essere integrata correttamente inline nella rete esistente.
• La sede non necessita di tag VLAN attraverso questo percorso RED.
• Il traffico locale e quello nel tunnel possono essere verificati separatamente con Packet Capture e test verso destinazioni reali.

Manual/Split: Gateway locale con rotte statiche

Per una SD-RED, Manual/Split descrive soprattutto un progetto di rete costruito deliberatamente in modo manuale. I lati WAN e LAN della RED vengono integrati nell’infrastruttura esistente in modo che il router continui a essere il gateway predefinito. Il router riceve rotte statiche verso la RED per le reti centrali.

Il vantaggio è l’autonomia locale: il normale accesso a internet può continuare anche se il tunnel RED o la RED stessa si interrompe. Lo svantaggio è una maggiore complessità di pianificazione. Percorsi di ritorno, rotte statiche, comportamento ARP e cablaggio fisico devono essere esatti. Un next hop errato può instradare il traffico centrale fuori dal tunnel o in un vicolo cieco durante un guasto.

Sophos descrive a questo scopo una distribuzione fisica manuale e una configurazione RED basata sullo schema Standard/Unified, mentre il gateway esistente e le rotte statiche determinano lo split. Il termine non va quindi trattato come un interruttore indipendente e autoesplicativo.

L’ordine fisico è importante: Per prima cosa, la porta WAN della RED viene collegata allo stesso switch LAN al quale sono collegati i client del sito. Solo dopo che la RED ha ricevuto la propria configurazione Standard/Unified, anche una porta LAN della RED viene collegata a questo switch. La RED non viene collocata in linea davanti all’intera LAN del sito. Prima del secondo collegamento devono essere chiarite la responsabilità DHCP esistente, l’indirizzo della RED come Next Hop e l’assegnazione delle porte dello switch; un server DHCP aggiuntivo non coordinato non deve assumere la configurazione dei client. Si tratta di un progetto di routing pianificato, non di una raccomandazione a collegare WAN e LAN tra loro su una qualsiasi RED.

Esempio di piano di routing: Il gateway esistente del sito 10.20.30.1 rimane il gateway dei client, mentre l’indirizzo LAN della RED previsto 10.20.30.2 funge da Next Hop per la rete centrale 10.10.40.0/24. Tutti i valori sono esempi adattabili; il Next Hop e il piano di indirizzamento devono corrispondere all’interfaccia RED effettivamente predisposta e non devono entrare in conflitto con i dispositivi esistenti. La sede centrale necessita del percorso di ritorno verso 10.20.30.0/24. Prima del rollout vengono verificati la risoluzione ARP verso il Next Hop, una destinazione centrale e l’accesso Internet locale. In caso di guasto del tunnel o della RED, il percorso Internet tramite 10.20.30.1 deve rimanere disponibile, mentre la destinazione centrale diventa indisponibile come previsto. In caso di comportamento DHCP, ARP o di routing imprevisto, scollegare il collegamento LAN della RED aggiunto per ultimo e ripristinare lo stato iniziale documentato di cablaggio e route.

Manual/Split va usato solo in un progetto documentato con:

• un gateway locale alternativo
• rotte statiche per ogni rete di destinazione centrale
• un percorso di ritorno verificato dalla sede centrale
• un accesso di gestione indipendente
• test con tunnel attivo, tunnel disconnesso e RED spenta

Opzioni Layer 2 e di espansione

Usare più RED come rete bridge condivisa

Un Bridged RED setup non è una quinta modalità operativa. In questa architettura si raggruppano almeno due interfacce RED esistenti in un bridge su Sophos Firewall. Le reti RED remote si comportano quindi come una LAN condivisa, mentre le regole firewall possono continuare a limitare il traffico tra le sedi RED.

Il bridge si crea in Network > Interfaces > Add interface > Add bridge. Si definiscono un nome chiaro e l’interfaccia bridge, quindi si selezionano le interfacce RED necessarie come Member interfaces con le rispettive zone. Il piano di indirizzamento, la responsabilità DHCP e tutti i membri del bridge devono essere coordinati in anticipo; più server DHCP non coordinati o indirizzi IP duplicati opererebbero infatti nella stessa rete Layer 2.

Consigliamo questa architettura solo quando più filiali richiedono realmente lo stesso dominio di broadcast. Per sedi normalmente separate, le reti RED instradate sono più semplici da isolare, monitorare e modificare in modo indipendente. Dopo il salvataggio vanno verificati DHCP, ARP, il traffico tra le sedi, la regola firewall responsabile e un traffico bloccato intenzionalmente. Un tunnel RED verde conferma i singoli tunnel, ma non il bridge né le sue regole.

Un secondo uplink e un secondo firewall non sono modalità operative

La configurazione RED può contenere anche un secondo endpoint firewall e, a seconda del modello e della modalità, un secondo uplink. Queste opzioni completano il percorso scelto, ma non lo sostituiscono.

Un secondo endpoint firewall può essere usato per failover o bilanciamento del carico. Un secondo uplink può proteggere la creazione del tunnel. Se entrambi gli uplink sono impostati su Static, gli indirizzi IP dei rispettivi server DNS devono essere diversi; non occorrono provider DNS differenti. Per la risoluzione DNS, la RED controlla la voce di routing del primo uplink. Se quel gateway non risponde, considera irraggiungibile l’IP del server DNS e non riprova a raggiungere lo stesso indirizzo IP tramite il secondo uplink.

Per il secondo endpoint del firewall vengono impostati 2nd firewall IP/hostname e Use 2nd IP/hostname for; 2nd uplink connection e 2nd uplink mode gestiscono un secondo collegamento WAN. Failover utilizza il secondo percorso in caso di guasto del primo, mentre Load balancing distribuisce il traffico su entrambi. Load balancing non sostituisce quindi un percorso di failover testato. 3G/UMTS failover richiede un dongle USB adatto e i parametri della rete mobile del provider. Il firmware RED 2.0.018 non supporta il D-Link DWM-222; un collegamento mobile di riserva pianificato deve essere compatibile con il firmware e l’hardware effettivi.

Collegamento mobile di riserva della RED: corrispondenza dei parametri del provider

Se il modello RED utilizzato, la modalità operativa, il firmware RED e il dongle USB supportano questo collegamento di riserva, modificare l’interfaccia RED interessata in Network > Interfaces e verificarne le impostazioni 3G/UMTS failover. In Transparent/Split questo failover mobile non è disponibile. La seguente corrispondenza illustra i parametri RED della documentazione API per SFOS 22.0 e 23.0; non è né un esempio XML eseguibile né una garanzia di supporto attuale della connettività mobile per SD-RED 20 o 60. I vecchi nomi dei modelli e le opzioni di connettività mobile nell’esempio API non sostituiscono una verifica di compatibilità della combinazione specifica.

• UMTS3GFailover: attivazione del collegamento mobile di riserva della RED; la documentazione indica Enable e Disable, con Disable come valore predefinito. Attivare solo dopo la verifica di compatibilità.
• Username e Password: nome utente e password per l’accesso alla rete mobile secondo le indicazioni del provider, non le credenziali dell’amministratore del firewall. Inserire solo le credenziali richieste dal provider; non utilizzare valori predefiniti inventati.
• Pin: PIN della scheda SIM utilizzata, se su di essa è configurato un PIN. Non confonderlo con il codice di sblocco della RED e, se il PIN non è noto con certezza, non rischiare di bloccare la SIM con tentativi ripetuti.
• MobileNetwork: tipo di rete mobile. I valori documentati sono GSM e CDMA, con GSM come valore predefinito; la scelta deve corrispondere alla combinazione provider/dongle effettivamente supportata. Questi vecchi valori di selezione non dimostrano la disponibilità attuale della rete.
• APN: Access Point Name del provider per quella specifica SIM o tariffa. Non è l’indirizzo pubblico del firewall e non viene ricavato dal nome del tunnel RED.
• DialString: stringa di composizione del provider per la combinazione supportata. Non adottare indiscriminatamente il valore di esempio/predefinito documentato: non esiste una stringa di composizione universale per tutti i provider e modem.

Questi valori riguardano la RED nella sede remota: nell’esempio API documentato, i campi del provider si trovano sotto UplinkSettings / FailOverSettings. Cellular WAN su Sophos Firewall configura invece la connessione mobile del firewall stesso; i campi del provider con lo stesso nome presenti in quella sezione non configurano un collegamento di riserva della RED. La corrispondenza è un ausilio all’inserimento, non una raccomandazione per un payload API o un serializzatore non verificato.

Prima di una modifica, salvaguardare l’uplink RED funzionante, l’impostazione di failover precedente e un percorso di gestione indipendente. Conservare la password del provider, il PIN della SIM e i file di provisioning solo in modo protetto e con accesso limitato; non copiarli in screenshot, ticket o esempi di configurazione. Se manca una compatibilità hardware/firmware confermata o un parametro del provider, non attivare il collegamento di riserva sulla base di supposizioni, ma chiarire la situazione con il provider o con Sophos Support. Dopo una modifica approvata, si applicano le verifiche separate dell’uplink e del percorso riportate di seguito; se il collaudo fallisce, ripristinare le impostazioni RED precedenti.

I test devono rimanere separati:

1. La modalità RED scelta deve prima funzionare correttamente tramite l’uplink primario.
2. Successivamente si prova un failover controllato dell’uplink.
3. Poi si verificano nuovamente stato RED, DHCP, destinazioni centrali e percorso internet.
4. Negli ambienti HA si aggiunge un test separato di failover del firewall; il tunnel RED necessita di tempo per ristabilirsi dopo il cambio di ruolo.

Lo stato verde del tunnel da solo non dimostra né il corretto percorso internet né il funzionamento delle policy di sicurezza.

VLAN e modalità delle porte LAN su SD-RED 60

La SD-RED 60 può trasportare VLAN nel tunnel, ma solo in Standard/Unified. Inoltre, per ogni porta LAN viene definito come la RED tratta i frame taggati e non taggati.

• Tagged: Vengono inoltrate con tag solo le VLAN configurate. Le VLAN non configurate e i frame non taggati vengono scartati. È possibile inserire fino a 64 VLAN ID per porta.
• Untagged, drop tagged: I frame non taggati vengono assegnati alla VLAN configurata; i frame già taggati vengono scartati. Corrisponde a una porta access controllata.
• Disabled: La porta LAN scarta il traffico.
• Untagged: I frame non taggati ricevono la VLAN ID configurata, mentre quelli già taggati vengono inoltrati senza modifiche. È possibile una sola configurazione VLAN per porta. Si tratta di una porta ibrida, non di un trunk liberamente configurabile; le VLAN consentite devono comunque essere controllate sullo switch collegato e sul firewall.

Le assegnazioni sopra riportate descrivono principalmente i frame in ingresso sulla porta LAN della RED. Per la direzione opposta, la modalità LAN Untagged descrive l’uscita della VLAN-ID configurata senza tag, per consentire il collegamento di un dispositivo terminale senza supporto VLAN. A tale scopo è previsto un ID in LAN VID(s); con Tagged vengono inseriti più ID separati da virgole, ad esempio 10,20. I numeri sono esempi per le proprie VLAN e devono corrispondere allo switch e al firewall.

Le descrizioni delle modalità LAN non sono univoche in ogni direzione: La tabella del traffico descrive lo scarto dei frame in ingresso con tag sulla porta di accesso, mentre il testo di Untagged, drop tagged descrive in modo contraddittorio l’uscita dei frame VLAN corrispondenti. Da ciò non viene qui dedotto alcun comportamento garantito in uscita o di isolamento. Prima dell’impiego in produzione, sul modello e sulla release effettivamente utilizzati vengono testati in entrambe le direzioni le VLAN consentite e non consentite e i frame senza tag. Prima, salvare la modalità della porta, LAN VID(s) e la configurazione dello switch e predisporre un percorso di gestione indipendente. In caso di inoltro imprevisto, rimuovere la porta di test dalla rete di produzione, ripristinare le impostazioni precedenti di porta e VLAN e verificare nuovamente; non improvvisare consentendo indiscriminatamente le VLAN.

Se una VLAN guest dietro la RED deve accedere localmente a Internet, Standard/Split non sostituisce questo progetto VLAN. Una possibile architettura prevede un Sophos Firewall aggiuntivo su una XGS Appliance di classe desktop presso il sito, che instradi questo traffico tramite il gateway locale e lo protegga lì. Si tratta di un percorso di routing e sicurezza distinto, che deve essere pianificato con regole separate, percorsi di ritorno e un test negativo di accesso dalla rete guest alla rete interna; la sola modalità operativa della RED non fornisce questa separazione.

Sophos Firewall necessita di un’interfaccia VLAN corrispondente sull’interfaccia RED per ogni VLAN utilizzata. VLAN ID, rete IP, DHCP, modalità della porta RED e configurazione dello switch devono corrispondere esattamente. La procedura completa è descritta in Configurare e testare una VLAN su Sophos Firewall.

Pianificare separatamente il comportamento wireless

Prima di configurare un modulo wireless, deve esistere un’interfaccia RED con un indirizzo IP e la risoluzione DNS deve funzionare proprio su quell’interfaccia. Un modulo wireless opzionale della SD-RED 20 o 60 può usare tre percorsi dati diversi:

• Separate zone: Il traffico wireless raggiunge il firewall in forma cifrata tramite VXLAN indipendentemente dalla modalità RED. Sophos Firewall deve consentire esplicitamente il traffico della zona separata per l’interfaccia RED; ciò non implica un’autorizzazione generale verso la WAN.
• Bridge to AP LAN: La rete wireless viene collegata alla LAN locale dell’access point.
• Bridge to VLAN: La rete wireless viene assegnata a una VLAN; il comportamento esatto dipende dalla modalità RED e dalla configurazione VLAN.

In Standard/Unified e Standard/Split, sull’interfaccia RED deve essere attivo un server DHCP configurato correttamente. Nello scenario wireless documentato di Transparent/Split, la rete remota fornisce DHCP e DNS e l’interfaccia RED deve ottenere il proprio indirizzo IP dal server DHCP remoto. Quel server deve fornire l’opzione 234 con l’indirizzo IP dell’interfaccia RED nella sede del firewall. Senza questa opzione, il valore di fallback documentato è 1.2.3.4: è un indizio diagnostico di un’opzione mancante, non un indirizzo da configurare in produzione. Impostazioni wireless, modalità della porta LAN e modalità RED vanno quindi collaudate come un unico progetto, non come tre menu indipendenti.

Bridge to VLAN non trasforma una modalità split in un trasporto VLAN generale. In Standard/Split, i client wireless raggiungono gli host locali con lo stesso tag e, se presente sull’interfaccia RED, l’interfaccia VLAN all’endpoint del tunnel. Non raggiungono le reti split configurate perché la RED le instrada solo per pacchetti non taggati. In Transparent/Split, la stessa VLAN si estende localmente sulle porte LAN 1–4 e sulla porta WAN; le reti split restano irraggiungibili attraverso questo percorso wireless.

Con Bridge to AP LAN, il bridge locale comprende le porte LAN 1–4. I client WLAN possono raggiungere l’interfaccia dell’endpoint del tunnel RED sul firewall solo se il traffico dalla rete RED verso tale interfaccia è consentito. Con Bridge to VLAN in Standard/Unified, i client WLAN ricevono la VLAN-ID configurata e possono raggiungere i dispositivi con la stessa VLAN-ID sulle porte LAN, secondo le autorizzazioni corrispondenti, nonché l’interfaccia VLAN appropriata sull’endpoint del tunnel del firewall. Un accesso WLAN riuscito non conferma ancora queste destinazioni; vengono verificate singolarmente con un client di test WLAN.

Configurare e testare la modalità in sicurezza

Prerequisiti e campi esatti

Attivare prima il servizio in System services > RED, quindi creare o modificare l’appliance in Network > Interfaces > Add interface > Add RED. I campi principali sono RED ID, Unlock code, Firewall IP/hostname, Device deployment, Uplink connection, RED operation mode, RED IP, Zone, Configure DHCP, RED DHCP range e, nelle modalità split, Split network.

RED ID è riportato sul dispositivo e sulla confezione; Tunnel ID deve essere libero su entrambi i dispositivi coinvolti. Firewall IP/hostname indica l’indirizzo pubblico raggiungibile o il nome pubblico dell’endpoint del tunnel, non un qualsiasi indirizzo interno di gestione. Durante la prima registrazione, Unlock code rimane vuoto. Per una RED già utilizzata o per il passaggio a un altro firewall, il codice esistente deve essere salvato e utilizzato. L’indirizzo di contatto in System services > RED deve essere corretto: quando si elimina un’interfaccia, il codice viene visualizzato e inviato a tale indirizzo. Se manca il codice, coinvolgere Sophos Support e non eliminare frettolosamente l’interfaccia funzionante.

Per il deployment automatico, la RED deve avviarsi almeno una volta in una rete con DHCP e accesso a internet per scaricare la configurazione. Un uplink statico richiede il deployment manuale tramite chiavetta USB. Il percorso deve consentire TCP 3400, UDP 3410 e NTP 123: configurazione e canale di controllo usano TCP 3400, mentre il tunnel dati Layer 2 usa UDP 3410. Senza un indirizzo WAN DHCP durante il deployment automatico, il dispositivo si riavvia ripetutamente.

Durante il provisioning automatico, il servizio di provisioning memorizza l’indirizzo del firewall, i parametri WAN e della rete mobile, la modalità operativa e l’Unlock Code. La RED risolve red.astaro.com e scarica la propria configurazione dal servizio di provisioning. Una RED funzionante non interroga continuamente questo servizio; se la configurazione non funziona, vi cerca istruzioni aggiornate. La raggiungibilità del servizio di provisioning e quella dell’effettivo endpoint del tunnel del firewall sono quindi verifiche separate. Per il provisioning USB, in Network > Interfaces, aprire il Menu dell’interfaccia RED corretta, selezionare Download provisioning file e copiare il file corrente nella directory radice della chiavetta USB. La verifica dettagliata dell’avvio e delle tempistiche è riportata nella procedura di configurazione collegata.

Consigliamo una zona dedicata di tipo LAN o DMZ invece della zona LAN generale. Se la modifica di RED IP sposta l’interfaccia RED in una subnet che non contiene più l’attuale RED DHCP range, SFOS disattiva il server DHCP RED. Questa dipendenza deve comparire nel piano di modifica.

Dopo una modifica di RED IP, adattare il server DHCP esistente in Network > DHCP oppure creare un nuovo server per la nuova rete. Verificare non solo l’intervallo dinamico, ma anche Dynamic IP lease, Static IP MAC mapping, gateway, DNS e altre opzioni. Un test del client con lease rinnovato deve mostrare i nuovi valori effettivi prima di riabilitare la filiale all’uso.

Allineare routing, regole firewall e NAT alla modalità

Creare le regole in Rules and policies > Firewall rules tra la zona RED e le sole zone di destinazione necessarie. Usare Any per reti e servizi soltanto durante un test funzionale limitato nel tempo; in produzione restringere sorgenti, destinazioni e servizi al fabbisogno reale. In Standard/Unified una regola RED-to-LAN non sostituisce una regola RED-to-WAN; il percorso internet centrale richiede anche una regola SNAT adeguata.

In Standard/Split è la RED a mascherare il traffico internet locale con il proprio indirizzo pubblico. Questo percorso non compare sul firewall centrale e non richiede lì una regola WAN SNAT. Il traffico nel tunnel verso la centrale richiede invece rotte di andata e ritorno corrette e regole corrispondenti; le regole NAT esistenti non devono tradurre involontariamente le reti sorgente o destinazione. In Manual/Split, testare come coppia le rotte statiche sul gateway della filiale e il percorso di ritorno in centrale.

Non utilizzare le opzioni aggiuntive per correggere la modalità

MAC filtering type distingue tra Allow list e Block list; il numero massimo di indirizzi MAC dipende dal modello del dispositivo. I filtri MAC non sostituiscono le regole del firewall e non correggono un routing errato. In PoE settings, su SD-RED 60 è possibile attivare una o entrambe le porte PoE; PoE riguarda l’alimentazione elettrica, non la modalità del tunnel.

Remote IP assignment in Advanced settings assegna un indirizzo tramite DHCP o Static al bridge con il tunnel RED sul lato WAN. Questa opzione è prevista solo nel caso in cui i dispositivi dietro la RED non rispondano alle richieste ARP. Prima di una modifica, documentare i risultati ARP e il valore precedente, quindi ripetere esattamente lo stesso test della destinazione e ripristinare il valore precedente se non si riscontra alcun miglioramento.

Anche Tunnel compression e MTU non modificano la selezione split. La compressione può aiutare con dati adatti e connessioni lente; MTU indica la dimensione massima dei pacchetti in byte. Non adottare un valore generico senza riscontri. I test controllati prima e dopo, i percorsi di ritorno e la raccomandazione di disattivare 802.3az sugli switch collegati direttamente sono riportati in Configurare Sophos SD-RED e risolvere i problemi.

Cambio modalità e rollback che preserva lo stato

Prima della modifica, registrare configurazione RED completa, RED IP, zona, intervallo e opzioni DHCP, reti split, rotte statiche, regole firewall e NAT, interfacce VLAN, modalità delle porte LAN e un accesso di gestione indipendente. Salvare anche l’ultima configurazione funzionante del router e delle porte switch coinvolte. Modificare un livello alla volta: modalità e rete RED, poi DHCP, routing e regole, infine VLAN o wireless.

Se il collaudo fallisce, non aggiungere altre modifiche in parallelo. Ripristinare RED operation mode, RED IP, zona, DHCP e reti split ai valori registrati, reintegrare rotte e regole precedenti e rinnovare il lease su un client di prova. Il rollback termina solo quando gateway, DNS, destinazione centrale, percorso internet e Rule ID corrispondono di nuovo alla baseline. In Manual/Split va ripristinato anche il cablaggio originario.

La procedura pratica con provisioning, LED, regole, prestazioni e risoluzione dei problemi è descritta in Configurare e risolvere i problemi di Sophos SD-RED. La modalità richiede inoltre il collaudo del percorso reale:

1. Un client riceve l’indirizzo IP atteso, i server DNS e il gateway corretto.
2. Una rete di destinazione definita nella sede centrale è raggiungibile.
3. Log Viewer o Packet Capture mostra la Firewall Rule ID attesa e il percorso RED.
4. Un test internet mostra l’uscita pubblica attesa, centrale o locale.
5. Un’applicazione consentita e una bloccata confermano dove si applica realmente la policy di sicurezza.
6. VLAN e reti wireless vengono testate singolarmente, non solo con un ping generico.
7. Un guasto pianificato del tunnel o dell’uplink conferma il comportamento documentato.

Se il tunnel è verde ma il percorso rimane poco chiaro, può aiutare Usare correttamente Packet Capture su Sophos Firewall. Nelle sedi produttive non si devono modificare contemporaneamente modalità, DHCP, VLAN e regole firewall. Altrimenti diventa quasi impossibile attribuire un errore a un singolo livello.

Risoluzione dei problemi in base al percorso dati

• La RED si riavvia ripetutamente o non crea il tunnel: controllare prima DHCP sulla WAN, DNS e accesso a internet nella filiale, poi TCP 3400, UDP 3410 e sincronizzazione NTP 123. Nel deployment manuale offline, un orologio errato può impedire l’handshake TLS.
• Il tunnel è verde, ma non passa traffico: cercare la Firewall Rule ID prevista in Log Viewer, quindi verificare rotte e regole NAT per la coppia sorgente/destinazione. In Advanced Shell, la cattura in sola lettura documentata da Sophos tcpdump -ni any port 3410 mostra se il traffico RED raggiunge il firewall. Non prova che una regola lo consenta né che il payload segua il percorso corretto; proseguire con Packet Capture filtrato per client e destinazione.
• Falliscono solo le destinazioni split: verificare che la rete di destinazione completa sia presente in Split network. Gli host FQDN non sono supportati. In Transparent/Split testare separatamente il DNS locale o split DNS.
• Fallisce solo il traffico VLAN: controllare prima la modalità. SD-RED 60 trasporta le VLAN nel tunnel solo in Standard/Unified. Confrontare poi VLAN ID, interfaccia VLAN sull’interfaccia RED, modalità porta LAN, tagging dello switch, DHCP e regola specifica per la VLAN.
• Si è verificato un failover HA: SFOS documenta un ritardo di riconnessione variabile in base al numero di interfacce e ad altre impostazioni. Attendere che il tunnel venga ristabilito e ripetere tutti i test del percorso senza cambiare contemporaneamente i parametri RED.

Errori di interpretazione comuni

Split non significa automaticamente internet durante un guasto del tunnel

Standard/Split usa il breakout internet locale, ma i client dipendono comunque dalla rete RED fornita dal firewall. Sophos documenta anche in questo caso la perdita dell’accesso a internet quando il tunnel si interrompe. Manual/Split è il progetto separato per un gateway locale esistente.

Transparent non significa passthrough Layer 2 arbitrario

Transparent/Split integra la RED in una rete esistente, ma non trasporta frame taggati con VLAN attraverso questo percorso. Anche DHCP, DNS e le opzioni wireless devono essere pianificati consapevolmente.

Un tunnel verde non dimostra che la modalità sia corretta

Lo stato del tunnel conferma la connessione al firewall. Solo i test di DHCP, routing, internet, regole e guasti mostrano se la modalità scelta corrisponde al progetto previsto.