Sostituire il tagging VLAN legacy 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.
Gli stessi servizi firewall devono raggiungere un tag VLAN.
Dopo un aggiornamento, AD, DNS, autenticazione, monitoraggio o accesso di gestione funzionano solo parzialmente.
Il normale traffico client attraverso il bridge sembra essere ancora in esecuzione.
È pianificato un upgrade a SFOS 22.0 MR2 o successivo oppure l’upgrade è bloccato dal legacy CLI VLAN tagging.

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é finisce davanti al 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 un obiettivo in un tag VLAN.
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.

Includi il design 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.
IP indirizzo del bridge, se disponibile.
VLAN ID che passano sul ponte.
Cambia profilo porta: Tagged VLAN, Native VLAN, Trunk o porta di accesso.
Servizi che terminano sul firewall: DNS, Ping, HTTPS, SSH, User Portal, VPN Portale.
Servizi che il firewall deve raggiungere: AD, LDAP, RADIUS, DNS, NTP, Syslog, Centrale, 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 traffico VLAN tagged sui bridge. Da SFOS 18.0 VLAN-over-bridge è disponibile in WebAdmin. Per il seguente comando CLI non sono specificati Device Console, Advanced Shell, numero di menu, prompt o livello di privilegio. Usa esclusivamente il contesto CLI supportato del firewall in cui il comando è disponibile. Se non lo è, fermati e chiedi a Sophos Support invece di ipotizzare shell o contesto. Verifica la configurazione legacy con questo comando di sola lettura:

system vlan-tag show

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:

Esporta un backup a scopo documentale, ma non considerarlo ripristinabile per il rollback su SFOS 22.
Documentare il bridge corrente e la configurazione VLAN.
In Network > Interfaces, seleziona Add interface > Add VLAN.
Seleziona il bridge come interfaccia principale, ad esempio br0.
Inserisci l’ID VLAN.
Scegli la tua zona consapevolmente.
Imposta l’indirizzo IP sull’interfaccia VLAN se il firewall deve trovarsi in questo VLAN Gateway o nel servizio locale.
Controlla Device Access per la zona.
Controlla le regole del firewall e le regole NAT.
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 un cambiamento che rischia di fallire. È opportuno chiarire in anticipo:

Quale indirizzo viene utilizzato per raggiungere WebAdmin?
Quali client utilizzano il firewall come predefinito Gateway?
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 sul bridge interessato IP, un errore può interrompere l’accesso amministrativo.

Rimuovere la configurazione legacy e preparare l’upgrade

Crea prima tutte le interfacce VLAN necessarie in Network > Interfaces con il bridge come parent, sposta se necessario l’IP del bridge sull’interfaccia VLAN corretta e valida i percorsi dati e amministrativi. In HA, verifica dall’interfaccia di stato supportata che peer e sincronizzazione siano integri ed esegui il backup di ogni nodo quando previsto dalla piattaforma e dalla procedura di supporto. Se lo stato non è integro o è incerto, fermati prima del reset o dell’upgrade ed esegui l’escalation; non inventare comandi HA o di sincronizzazione. Con mapping documentato, accesso alternativo attivo e prerequisiti HA soddisfatti, rimuovi l’impostazione nello stesso contesto CLI supportato descritto sopra:

system vlan-tag reset

Esegui nuovamente system vlan-tag show. Se resta una configurazione, il reset fallisce o l’output è ambiguo, fermati: non avviare l’upgrade e non approvare il nuovo backup come restore point pulito. Salva output, precheck e configurazione e contatta Sophos Support senza comandi non documentati. Non esiste un’inversione documentata a livello di comando per system vlan-tag reset: superare i controlli conferma la pulizia, non il rollback. Dopo il reset non ricreare l’impostazione legacy con un comando ipotizzato. Se la modifica deve essere annullata, fermati ed esegui l’escalation per un ripristino approvato dal vendor sul firmware originale supportato. Dopo i test, crea un nuovo backup, ripeti il precheck e solo allora esegui l’upgrade. Per un backup ripristinabile, pulisci allo stesso modo il firewall sorgente, crea facoltativamente l’interfaccia VLAN necessaria, valida e poi crea il backup. Questo non ripara un vecchio backup con system vlan-tag.

Device Access e successivamente controlla le regole del firewall

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 portali Ping/Ping6, DNS, HTTPS, SSH, User Portal o VPN 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, Device Access configurare in modo sicuro Sophos Firewall è l’articolo approfondito appropriato. Sophos Firewall Regola di prova 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:

Raggiungi Gateway predefinito.
Testare il firewall IP sulla nuova interfaccia VLAN tramite ping, se consentito.
Testare il DNS rispetto al firewall se il firewall funge da risolutore DNS.
Testare WebAdmin o il portale solo dalle reti di gestione consentite.
Controllare un’applicazione tipica o una connessione al server.
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.
Seleziona NTP, Syslog o il target di monitoraggio se questi servizi sono in 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, è necessario selezionare anche Configura STAS su Sophos Firewall. Per gli aggiornamenti SFOS-22, questo punto appartiene anche al SFOS 22 Upgrade Check.

Rollback e completamento

Prima della modifica, annota indirizzo IP e zona del bridge, ID VLAN, profilo della porta dello switch e regole e servizi dipendenti. Prepara un accesso di gestione alternativo o locale e un piano di ripristino approvato dal vendor. Prima di system vlan-tag reset, le modifiche WebAdmin pianificate possono essere annullate nell’ordine documentato: rimuovi prima l’IP dall’interfaccia VLAN e poi riassegnalo al bridge; ripristina zona, regole, Device Access e profilo dello switch e verifica la connettività. Questo non annulla il reset. Dopo il reset non esiste un’inversione documentata a livello di comando: se la verifica fallisce, fermati ed esegui l’escalation per un ripristino approvato sul firmware originale supportato. In HA, non resettare né aggiornare alcun nodo se peer o sincronizzazione non sono integri o sono incerti e conserva il backup applicabile di ogni nodo.

Dopo una verifica riuscita, crea un nuovo backup. Il vecchio backup con legacy CLI VLAN tagging non è un rollback valido per SFOS 22.0 GA o versioni successive. Se il precheck continua a segnalarlo, salva configurazione e messaggio e contatta Sophos Support senza provare altre modifiche CLI non documentate.

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. Local Service ACL pianifica in modo specifico.
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.
Limite di ripristino documentato: nessuna inversione documentata per system vlan-tag reset; nuovo backup creato dopo la correzione.
Risultato registrato nel registro delle modifiche o nella documentazione di rete.

Domande frequenti

Perché il traffico normale funziona attraverso il bridge ma il DNS al firewall no?

In questo caso speciale SFOS-22, il traffico VLAN passato può continuare a funzionare, mentre il traffico contrassegnato con VLAN che termina o ha origine dal firewall viene influenzato. Pertanto, è necessario testare separatamente i servizi firewall locali.

In generale dovresti evitare le VLAN bridge su Sophos Firewall?

Non generalmente. I bridge possono essere utili per migrazioni o progetti trasparenti. Per le nuove reti segmentate, tuttavia, le interfacce VLAN separate con zone libere sono generalmente più chiare e più facili da utilizzare.

Il problema può essere risolto con una regola del firewall?

Non affidabile. Se la progettazione dell’interfaccia viene influenzata, un’ulteriore regola Consenti non modificherà la causa. Per prima cosa dovresti verificare se VLAN deve essere creato correttamente come interfaccia sul bridge.

Cosa dovresti controllare prima di apportare modifiche al bridge IP?

È necessario chiarire se WebAdmin, DNS, DHCP, Gateway predefinito, autenticazione o monitoraggio utilizzano questo indirizzo. Inoltre sono necessari un backup attuale e un percorso di accesso alternativo.