Sostituire il tagging VLAN legacy sui bridge prima di SFOS 22 MR2

Le interfacce bridge di Sophos Firewall sono utili per mantenere trasparente una rete Layer 2 esistente o per eseguire una migrazione senza modificare subito gli indirizzi IP. Se in precedenza i tag VLAN sono stati configurati su un bridge con system vlan-tag, sostituiscili con interfacce VLAN in WebAdmin prima di eseguire l’upgrade a SFOS 22.0 MR2 o versioni successive. Non è una modifica puramente estetica: in GA e MR1 il traffico destinato al firewall o generato dal firewall può interrompersi, mentre da MR2 la configurazione legacy blocca l’upgrade.

Il problema NC-181672 riguarda le interfacce bridge con configurazioni CLI VLAN tag in SFOS 22.0 GA e SFOS 22.0 MR1: il traffico con tag VLAN che ha origine da Sophos Firewall o termina nel firewall non viene elaborato correttamente. Ciò può influire su Active Directory, DNS, Device Access, STAS, LDAP, RADIUS o sull’accesso alla gestione, anche se il bridge continua a inoltrare il traffico normale.

Il tagging VLAN legacy da CLI è obsoleto: blocca l’upgrade a SFOS 22.0 MR2 o versioni successive e un backup che lo contiene non può essere ripristinato su SFOS 22.0 GA o versioni successive. Esegui quindi il controllo prima dell’upgrade e prima di creare il backup destinato all’operazione. Il controllo dell’upgrade a SFOS 22 documenta la release di destinazione verificata MR2 Build 546, il relativo percorso di upgrade e altri blocchi specifici della versione. Se è prevista una build diversa, questa verifica interna deve essere aggiornata prima del change; i dati di MR2 non vanno trasferiti senza verifica.

Questo articolo non è un capitolo generale sulle VLAN. Per pianificare zone, interfacce, VLAN, Bridge e LAG, conviene iniziare da Configurare zone e interfacce su Sophos Firewall. La normale procedura di configurazione, protezione e verifica è descritta in Configurare un’interfaccia Bridge su Sophos Firewall. Qui viene trattato specificamente il caso particolare delle VLAN su Bridge dopo SFOS 22.

Quando questo argomento è rilevante

Il controllo ha senso quando più punti confluiscono:

• Il firewall funziona su SFOS 22.0 GA o SFOS 22.0 MR1.
• Esiste un’interfaccia bridge, ad esempio br0.
• Storicamente le VLAN venivano create utilizzando la configurazione del tag CLI VLAN come system vlan-tag o venivano riprese da una vecchia configurazione.
• I servizi del firewall devono raggiungere una VLAN con traffico tagged.
• Dopo un aggiornamento, AD, DNS, autenticazione, monitoraggio o accesso di gestione funzionano solo parzialmente.
• È pianificato un upgrade a SFOS 22.0 MR2 o successivo oppure l’upgrade è bloccato dal legacy CLI VLAN tagging.
• Il normale traffico client attraverso il bridge sembra continuare a funzionare.

L’ultimo punto è importante: se il bridge continua a inoltrare il traffico tra le reti, inizialmente il problema non sembrerà un guasto del bridge. In pratica è facile cercare nel posto sbagliato, ad esempio nelle regole del firewall, nel DNS, nello STAS o nel controller del dominio.

Comprendere la direzione del traffico interessata

Devi separare chiaramente tre tipi di traffico.

I tipi di traffico differiscono in modo significativo:

• Traffico passato attraverso il bridge: un client in VLAN 100 sta comunicando con un server in VLAN 100. Potrebbe continuare a funzionare, ma non dimostra che il traffico verso il firewall funzioni.
• Traffico verso il firewall: un client utilizza il firewall come server DNS o destinazione WebAdmin. È proprio questo traffico che può essere influenzato perché termina sul firewall.
• Traffico dal firewall: il firewall interroga le destinazioni AD, DNS, LDAP, RADIUS, NTP o Syslog. Anche questo è fondamentale perché il firewall stesso è il mittente.

Se viene testata una sola applicazione tra due host, l’errore non può essere identificato con certezza. Il test deve includere deliberatamente un servizio che termina su Sophos Firewall o viene creato dal firewall.

Sintomi tipici

I possibili segnali sono:

• Le regole basate sull’utente non funzionano più in modo affidabile perché AD, STAS o LDAP non possono essere raggiunti in modo stabile.
• Le query DNS al firewall non riescono da singole VLAN.
• Ping o HTTPS sui servizi firewall locali non funziona da VLAN, anche se le regole del firewall sembrano plausibili.
• Il monitoraggio o Syslog appare incompleto se il firewall deve raggiungere una destinazione in una VLAN con traffico tagged.
• Packet Capture mostra che il traffico tra i sistemi finali è visibile, ma i servizi firewall stessi non rispondono come previsto.
• Dopo un aggiornamento SFOS-22, i sintomi si verificano senza modificare consapevolmente nulla sulle regole dello switch o del firewall.

Tali sintomi non dovrebbero essere affrontati immediatamente con regole di autorizzazione generali o approvazioni di accesso ai dispositivi. Innanzitutto deve essere chiaro se il design dell’interfaccia stessa ne risente.

Demarcazione rapida prima della conversione

Prima di spostare un bridge IP o creare nuove interfacce VLAN sul bridge, dovresti restringere la causa. Non tutti i problemi dopo un aggiornamento rientrano automaticamente nel caso SFOS-22-Bridge-VLAN.

Classificazione pratica:

• Una sola applicazione tra due host non funziona: Più probabilmente sono la regola del firewall, NAT, il sistema di destinazione o il percorso di ritorno. Innanzitutto testare la regola del firewall e per le interruzioni analizzare i pacchetti eliminati.
• WebAdmin, DNS o ping al firewall da un VLAN non funziona: Controlla Device Access, zona, servizio locale o bridge VLAN caso speciale. Quindi testare separatamente il traffico verso il firewall.
• Il firewall non raggiunge AD, LDAP, RADIUS, DNS o Syslog in VLAN: Controlla il traffico dal firewall, dal routing, dal DNS o dal bridge VLAN caso speciale. Utilizza i test direttamente dalla configurazione del firewall e dai registri di servizio appropriati.
• Il traffico client normale è in esecuzione, ma i servizi del firewall stesso no: Diventa più probabile il caso speciale Bridge VLAN. Controlla il design del bridge, la vecchia configurazione del tag CLI VLAN e l’interfaccia VLAN per il bridge.
• Non ci sono voci di log corrispondenti: Controlla logging, filtro, servizio locale o bridge non registrato/NAT caso speciale. Combina Log Viewer, Packet Capture e i Sophos Firewall log di servizio pertinenti.

Per i problemi DNS è importante anche se i client utilizzano il firewall come risolutore o se il firewall stesso utilizza gli instradamenti delle richieste DNS ai server interni. Il secondo caso riguarda il traffico proveniente dal firewall e potrebbe apparire diverso dal normale traffico client per problemi di Bridge VLAN. Le nozioni di base si trovano in Configurazione dei percorsi di richiesta DNS su Sophos Firewall.

Se la rapida delimitazione indica chiaramente servizi firewall locali o traffico generato dal firewall, la conversione dovrebbe essere comunque pianificata. Una correzione del bridge senza backup, finestra di manutenzione e percorso di accesso alternativo è troppo rischiosa per le reti produttive.

Documentare la configurazione esistente

Prima di apportare modifiche, è necessario documentare lo stato attuale. Particolarmente importanti sono:

• Nome dell’interfaccia del bridge, ad esempio br0.
• Membri del bridge, ovvero interfacce fisiche, VLAN, interfacce RED o LAG partecipanti.
• Indirizzo IP del bridge, se presente.
• VLAN ID che passano sul ponte.
• Profilo della porta dello switch: VLAN tagged, Native VLAN, trunk o access port.
• Servizi che terminano sul firewall: DNS, Ping, HTTPS, SSH, User Portal, VPN Portal.
• Servizi che il firewall deve raggiungere: AD, LDAP, RADIUS, DNS, NTP, Syslog, Central, monitoraggio.

Se la struttura proviene da una vecchia migrazione, dovresti anche verificare se le VLAN sono state impostate tramite la configurazione CLI. È proprio questa eredità che spesso non viene più presa in considerazione quando il firewall nel corso degli anni è stato solo aggiornato.

⚠️ Non dovresti sperimentare spontaneamente interfacce bridge e VLAN durante le operazioni quotidiane. Una modifica errata può influire sull’accesso alla gestione, sul DNS, sull’autenticazione o su intere reti client. Prima della correzione sono necessari un backup, una finestra di manutenzione e un percorso di accesso alternativo.

Insidie specifiche del bridge prima della correzione

Prima della modifica devono essere verificate attentamente tre limitazioni dei bridge.

Primo: un bridge senza indirizzo IP può scartare traffico se il traffico corrisponde a una regola firewall con filtro web proxy o a una regola NAT. Questi drop non vengono registrati nei log. Se una regola NAT è comunque necessaria, deve essere limitata in modo che la source translation per il bridge senza indirizzo IP resti su Original. Altrimenti si rischia di cercare in Log Viewer un drop che non compare mai.

Secondo: il VLAN filtering sul bridge si applica solo al traffico bridged, non al traffico routed. Se Filter VLANs è attivato ma non sono inseriti VLAN IDs consentiti, il traffico taggato di tutti i VLAN viene scartato; il traffico non taggato ne è escluso. Durante i test, questo può sembrare un problema VLAN incoerente.

Terzo: le interfacce bridge non sostituiscono qualsiasi design. Esistono limitazioni per Dynamic DNS, DHCP client, PPPoE e IPsec VPN. Se una di queste funzioni fa parte del design di destinazione, il workaround bridge non va applicato in modo isolato; il design delle interfacce deve essere rivalutato.

Creare interfacce VLAN supportate

Il workaround supportato consiste nel creare interfacce VLAN in Network > Interfaces usando il bridge come parent. Le interfacce fisiche, RED, bridge e LAG sono parent validi.

Prima di SFOS 18.0, system vlan-tag era necessario per abilitare la comunicazione con tag VLAN sulle interfacce bridge. Da SFOS 18.0, VLAN-over-bridge è interamente disponibile in WebAdmin. Per l’inventario e la rimozione della configurazione legacy occorre tuttavia rispettare un limite importante: la documentazione sui tag VLAN per SFOS 22 e 23 descrive un reset con argomenti relativi all’interfaccia anche come visualizzazione della configurazione. Da questa descrizione non si può dedurre né che system vlan-tag show sia un comando autonomo di consultazione che non modifica la configurazione, né che system vlan-tag reset senza argomenti sia un comando di rimozione con un ambito di applicazione noto. Nemmeno la disponibilità di un comando in un contesto CLI conferma queste proprietà.

Prima di qualsiasi operazione CLI di inventario o rimozione, una documentazione inequivocabile per la build installata o Sophos Support deve confermare il metodo esatto per rilevare la configurazione esistente senza modificarla e la sintassi da utilizzare per la rimozione. La conferma deve includere il contesto CLI preciso, i privilegi e gli argomenti necessari, le interfacce o i nodi interessati, nonché gli effetti e l’ambito di applicazione della rimozione. Se questi aspetti non sono chiariti, documentare soltanto l’inventario visibile in WebAdmin in Network > Interfaces e fermarsi prima della rimozione o dell’upgrade. L’assenza di voci in WebAdmin non dimostra che non esistano tag legacy configurati da CLI; chiarire con Sophos Support la questione ancora aperta dell’inventario, invece di provare un presunto comando di visualizzazione o reset.

I design nuovi o ripuliti non dovrebbero più basarsi su system vlan-tag. Se questi tag CLI esistono ancora, è necessario documentarli, migrarli a interfacce VLAN in WebAdmin e solo dopo proseguire con l’upgrade firmware. Questo riduce sia il caso speciale bridge di SFOS 22 sia i blocchi di upgrade successivi.

Esempi:

• VLAN 100: br0.100
• VLAN 200: br0.200

Quando si crea il VLAN in WebAdmin, tre campi sono decisivi: Interface deve essere il bridge, Zone deve corrispondere allo scopo di sicurezza del VLAN e VLAN ID deve essere univoco. WebAdmin accetta ID VLAN da 1 a 4094; lo stesso VLAN ID non dovrebbe essere pianificato più di una volta sullo stesso parent interface.

Il processo dipende dal fatto che il bridge stesso abbia già un indirizzo IP.

Se il bridge non necessita di un indirizzo IP

Se il bridge deve solo inoltrare in modo trasparente, può essere utilizzato senza un proprio indirizzo IP. L’indirizzo IP per il VLAN interessato si trova quindi sull’interfaccia VLAN, ad esempio br0.100.

Processo pratico:

1. Esporta un backup a scopo documentale, ma non considerarlo ripristinabile per il rollback su SFOS 22.
2. Documentare il bridge corrente e la configurazione VLAN.
3. In Network > Interfaces, seleziona Add interface > Add VLAN.
4. Seleziona il bridge come interfaccia principale, ad esempio br0.
5. Inserisci l’ID VLAN.
6. Scegli la tua zona consapevolmente.
7. Imposta l’indirizzo IP sull’interfaccia VLAN se il firewall deve fungere da gateway o da servizio locale in questa VLAN.
8. Controlla Device Access per la zona.
9. Controlla le regole del firewall e le regole NAT.
10. Convalida la modifica con un client di prova e crea un nuovo backup solo dopo il superamento dei test.

La zona non è solo ordinata in WebAdmin. Questa decisione influisce sulle regole del firewall, Device Access, sui registri e su molti passaggi successivi per la risoluzione dei problemi. Se una VLAN è intesa come rete di gestione, server o client, questa dovrebbe essere visibile nella zona.

Se il bridge aveva in precedenza l’indirizzo produttivo IP

Se il bridge attualmente utilizza l’indirizzo IP, che in futuro dovrà essere accessibile in VLAN, dovresti prestare particolare attenzione. Esistono due varianti pulite per la conversione: il bridge riceve un indirizzo IP diverso oppure il bridge rimane senza indirizzo IP. L’indirizzo produttivo precedente viene quindi assegnato all’interfaccia VLAN.

Si tratta di una modifica con rischio di interruzione del servizio. È opportuno chiarire in anticipo:

• Quale indirizzo viene utilizzato per raggiungere WebAdmin?
• Quali client utilizzano il firewall come gateway predefinito?
• Quali impostazioni DNS o DHCP puntano a questo indirizzo?
• Quali regole di accesso ai dispositivi si applicano alla zona precedente?
• Esiste un secondo accesso di gestione da una rete non interessata?

Per le località remote, questo cambiamento non dovrebbe essere pianificato senza un percorso di ritorno locale. Se WebAdmin e SSH passano esattamente sull’indirizzo IP del bridge interessato, un errore può interrompere l’accesso amministrativo.

Rimuovere la configurazione legacy e preparare l’upgrade

L’ordine delle operazioni è fondamentale: dopo i chiarimenti descritti sopra, creare innanzitutto tutte le interfacce VLAN necessarie in Network > Interfaces, usando il bridge come Parent Interface, spostare se necessario l’indirizzo IP esistente del bridge sull’interfaccia VLAN appropriata e verificare i nuovi percorsi per il traffico dati e di gestione. In un ambiente HA, verificare preventivamente tramite la visualizzazione di stato supportata che il peer e la sincronizzazione non presentino anomalie ed eseguire il backup di ogni nodo, nella misura prevista dalla piattaforma e dalle procedure di supporto. Se lo stato del peer o della sincronizzazione presenta anomalie o non è chiaro, fermarsi prima della rimozione o dell’upgrade ed eseguire l’escalation. Non inventare comandi HA o di sincronizzazione.

Solo quando la corrispondenza è documentata, un accesso alternativo è attivo e tutti i prerequisiti HA sono soddisfatti, è possibile rimuovere l’impostazione legacy con la procedura confermata dalla documentazione per la build installata o da Sophos Support. La conferma della sintassi esatta, del contesto CLI, degli effetti e dell’ambito di applicazione alle interfacce e ai nodi deve essere disponibile prima dell’esecuzione; questo articolo non autorizza l’esecuzione di un comando di reset senza le necessarie precisazioni. In assenza di conferma, limitarsi all’inventario WebAdmin e fermarsi prima della rimozione o dell’upgrade.

Successivamente, utilizzare il metodo di inventario precedentemente confermato come non modificante per verificare in modo mirato che l’impostazione legacy sia stata rimossa nell’ambito previsto. I soli test del traffico non lo dimostrano. Se una configurazione legacy rimane visibile, la rimozione non riesce o l’inventario non è inequivocabile, interrompere la procedura: non avviare ancora l’upgrade e non approvare il nuovo backup come punto di ripristino privo della configurazione legacy. Salvare le evidenze disponibili dell’inventario, l’eventuale output dei comandi, il controllo preliminare dell’upgrade e la configurazione corrente, quindi eseguire l’escalation a Sophos Support; non provare comandi CLI non documentati.

La descrizione contraddittoria del reset non consente nemmeno di dedurre una procedura affidabile di rollback a livello di comando. Il superamento dei controlli dell’inventario e dei test del traffico conferma la rimozione, non la possibilità di rollback. Dopo la rimozione, non ricreare l’impostazione legacy con un comando ipotizzato. Se occorre annullare il change, fermarsi e coinvolgere Sophos Support per un ripristino approvato dal produttore sul firmware originale supportato; annullare le modifiche WebAdmin soltanto nell’ambito di questo piano approvato.

Se i test di accettazione e la nuova verifica dell’inventario hanno esito positivo, creare un nuovo backup, ripetere il controllo preliminare dell’upgrade e solo allora eseguire l’upgrade a SFOS 22.0 MR2 o versioni successive. Per ottenere una configurazione ripristinabile in futuro, applicare la stessa procedura di rimozione confermata: rimuovere l’impostazione legacy sul firewall di origine, creare se necessario un’interfaccia VLAN con il bridge come Parent, verificare e solo dopo generare un nuovo backup. Questa procedura non corregge un vecchio backup contenente system vlan-tag.

Verificare Device Access e le regole firewall dopo la modifica

Dopo aver creato l’interfaccia VLAN, non è sufficiente testare solo l’indirizzo IP. Device Access e le regole del firewall devono corrispondere alla nuova progettazione dell’interfaccia e della zona.

Per verificare:

• Administration > Device access: i servizi Ping/Ping6, DNS, HTTPS, SSH, User Portal o VPN Portal sono consentiti solo nelle zone corrette?
• Rules and policies > Firewall rules: Ci sono regole per la nuova zona?
• Rules and policies > NAT rules: il traffico viene tradotto in modo imprevisto?
• Network > DNS o percorsi di richiesta DNS: il firewall raggiunge i server DNS o AD corretti?
• Authentication > Servers: AD, LDAP o RADIUS sono accessibili dopo la modifica? Per i servizi firewall locali, Configurare Device Access in sicurezza su Sophos Firewall è l’articolo approfondito appropriato. Testare una regola Sophos Firewall con Log Viewer e Packet Capture aiuta nell’analisi delle regole.

Convalida dopo la correzione

Un test pulito dovrebbe contenere più di un ping.

Test dal VLAN interessato

Verifica da un client nelle VLAN interessate:

1. Raggiungi Gateway predefinito.
2. Testare il firewall IP sulla nuova interfaccia VLAN tramite ping, se consentito.
3. Testare il DNS rispetto al firewall se il firewall funge da risolutore DNS.
4. Testare WebAdmin o il portale solo dalle reti di gestione consentite.
5. Controllare un’applicazione tipica o una connessione al server.
6. Controlla Log Viewer per la corrispondenza tra ID regola e zona.

Prova dal firewall

Sono necessari test separati per il traffico generato dal firewall stesso:

• Testare i server AD o LDAP in Authentication > Servers.
• Controlla la risoluzione DNS tramite firewall.
• Verifica NTP, Syslog o la destinazione di monitoraggio se questi servizi si trovano nella VLAN.
• In Diagnostics > Packet capture, controlla l’interfaccia VLAN. Generated identifica i pacchetti creati dal firewall e Consumed quelli destinati al firewall; confronta anche In interface, Out interface, Rule ID, Status e Reason.

Se sono interessate le regole STAS o basate sull’utente, consultare anche Configurare STAS su Sophos Firewall. Per gli aggiornamenti SFOS-22, questo punto appartiene anche al SFOS 22 Upgrade Check.

Rollback e completamento

Prima del change, annotare l’indirizzo IP e la zona esistenti del bridge, i VLAN IDs, la configurazione delle porte dello switch, nonché le regole e i servizi dipendenti. Sono inoltre necessari un accesso di gestione alternativo o locale e un piano di ripristino approvato dal produttore. Finché la procedura confermata di rimozione tramite CLI non è stata eseguita, è possibile annullare le modifiche WebAdmin pianificate nell’ordine documentato: rimuovere prima l’indirizzo IP spostato dalla nuova interfaccia VLAN e solo dopo riassegnarlo al bridge; quindi ripristinare zona, regole, Device Access e profilo della porta dello switch e verificare la raggiungibilità della gestione e del gateway. Questa operazione non annulla una rimozione eseguita tramite CLI.

La descrizione contraddittoria del reset non dimostra che esista un’operazione inversa a livello di comando. Se i test di accettazione falliscono dopo la rimozione confermata, fermarsi e non ricreare l’impostazione legacy. Eseguire l’escalation per un ripristino approvato dal produttore sul firmware originale supportato. In HA, non rimuovere la configurazione né eseguire l’upgrade su alcun nodo finché lo stato del peer o della sincronizzazione presenta anomalie o non è chiaro; conservare il backup richiesto per ciascun nodo. Senza la conferma preventiva necessaria del metodo di inventario, della sintassi di rimozione, del contesto, degli effetti e dell’ambito di applicazione, limitarsi all’inventario WebAdmin e fermarsi prima della rimozione o dell’upgrade.

Dopo il superamento dei test di accettazione, creare un nuovo backup. Il vecchio backup con Legacy CLI VLAN tagging non costituisce un percorso di rollback per SFOS 22.0 GA o versioni successive. Se la configurazione legacy permane nonostante la migrazione in WebAdmin o il controllo preliminare dell’upgrade continua a segnalarla, non sperimentare ulteriori modifiche CLI: salvare la configurazione e il messaggio e coinvolgere Sophos Support.

Errori comuni

Insidie tipiche:

• Testare solo il traffico client-server: il bridge sembra integro, anche se i servizi firewall locali sono interessati. Testare anche il traffico da e verso il firewall.
• Sposta bridge IP senza piano: WebAdmin, DNS o Gateway potrebbero non funzionare. Preparare backup, finestre di manutenzione e accessi alternativi.
• Seleziona la zona in modo errato per la nuova interfaccia VLAN: Regole, Device Access e registri non si adattano. Scegli una zona in base a motivi di sicurezza, non in base all’abitudine.
• Device Access aperto troppo: Il problema sembra risolto, ma i servizi di gestione sono inutilmente accessibili. Pianifica le Local Service ACL in modo mirato.
• Non controllare la porta dello switch: VLAN arriva errato o senza tag. Convalida il profilo Tagged/Untagged, Native VLAN e Trunk.
• Ignora la vecchia configurazione CLI: L’errore rimane inspiegabile dopo l’aggiornamento. Documenta il vecchio design ed esegui la migrazione alle interfacce WebAdmin-VLAN.

Lista di controllo

• Verifica della pertinenza della versione SFOS e del problema noto.
• Interfaccia del bridge, membri del bridge e ID VLAN documentati.
• Chiarito se veniva utilizzata la vecchia configurazione del tag CLI VLAN.
• Drop specifici del bridge tramite NAT/web proxy e VLAN filtering controllati.
• Upgrade pianificato a SFOS 22.0 MR2 o successivo verificato rispetto ai legacy CLI VLAN tags.
• Identificati i servizi interessati da e verso il firewall.
• Backup di ogni nodo applicabile e accesso di gestione alternativo disponibili; peer e sincronizzazione HA integri.
• Interfaccia VLAN pianificata con bridge come interfaccia principale.
• Zona, Device Access, regole firewall e NAT controllate.
• Test effettuati dal VLAN e dal firewall.
• Metodo di inventario non modificante, sintassi esatta di rimozione, contesto CLI, effetti e ambito di applicazione confermati prima di qualsiasi operazione CLI dalla documentazione per la build installata o da Sophos Support; in caso contrario, solo inventario WebAdmin e arresto prima della rimozione o dell’upgrade.
• Limite di ripristino documentato: dalla descrizione contraddittoria del reset non è possibile dedurre un percorso di rollback a livello di comando; nuovo backup creato dopo la rimozione confermata e il superamento dei test di accettazione.
• Risultato registrato nel registro delle modifiche o nella documentazione di rete.

Domande frequenti