Ersätt äldre VLAN-taggning före SFOS 22 MR2

Brygggränssnitt på Sophos Firewall är användbara när ett befintligt Layer 2-nätverk ska förbli transparent eller vid en migrering utan omedelbara IP-ändringar. Om VLAN-taggar tidigare har konfigurerats på en brygga med system vlan-tag ska de ersättas med VLAN-gränssnitt i WebAdmin före uppgradering till SFOS 22.0 MR2 eller senare. Det är inte en kosmetisk ändring: i GA och MR1 kan trafik till eller från brandväggen sluta fungera, och från MR2 blockerar den äldre konfigurationen uppgraderingen.

Problemet NC-181672 påverkar brygggränssnitt med CLI-konfigurerade VLAN-taggar i SFOS 22.0 GA och MR1: VLAN-taggad trafik som kommer från eller är avsedd för Sophos Firewall hanteras inte korrekt. Det kan påverka Active Directory, DNS, Device Access, STAS, LDAP, RADIUS eller hanteringsåtkomst, även om bryggan fortsätter att vidarebefordra normal trafik.

Äldre VLAN-taggning via CLI är föråldrad: den blockerar uppgradering till SFOS 22.0 MR2 eller senare, och en backup som innehåller konfigurationen kan inte återställas till SFOS 22.0 GA eller senare. Utför därför kontrollen före uppgraderingen och innan du skapar den backup som ska användas för den. Uppgraderingskontrollen för SFOS 22 dokumenterar den verifierade målversionen MR2 Build 546, uppgraderingsvägen och andra versionsspecifika blockerare. Om en annan målbuild planeras måste den interna uppgraderingskontrollen uppdateras före ändringen; MR2-uppgifterna får inte överföras utan verifiering.

Den här artikeln är inte ett allmänt kapitel om VLAN. Börja planeringen av zoner, gränssnitt, VLAN, Bridges och LAG:er med Konfigurera zoner och gränssnitt på Sophos Firewall. Den normala konfigurationen, skyddet och kontrollen beskrivs i Konfigurera ett Bridge-interface på Sophos Firewall. Här behandlas specifikt det särskilda fallet med VLAN på Bridges efter SFOS 22.

När detta ämne är relevant

Kontrollen är vettig när flera punkter sammanfaller:

• Brandväggen körs på SFOS 22.0 GA eller SFOS 22.0 MR1.
• Det finns ett brygggränssnitt, till exempel br0.
• VLAN byggdes historiskt med CLI VLAN-taggkonfiguration som system vlan-tag eller togs över från en gammal konfiguration.
• Brandväggstjänster måste själva uppnå en taggad VLAN.
• Efter en uppgradering fungerar AD, DNS, autentisering, övervakning eller hanteringsåtkomst endast delvis.
• Normal kundtrafik genom bron verkar fortfarande vara igång.
• En uppgradering till SFOS 22.0 MR2 eller senare är planerad eller blockeras av legacy CLI VLAN tagging.

Den sista punkten är viktig: Om bron fortsätter att vidarebefordra trafik mellan nätverk, kommer problemet initialt inte att vara ett brofel. I praktiken är det lätt att leta på fel ställe, som brandväggsregler, DNS, STAS eller domänkontrollanten.

Förstå påverkad trafikriktning

Du måste tydligt separera tre typer av trafik.

Typerna av trafik skiljer sig markant:

• Trafik passerade genom bryggan: En klient i VLAN 100 pratar med en server i VLAN 100. Detta kan fortfarande fungera, men bevisar inte att trafiken till brandväggen fungerar.
• Trafik till brandvägg: En klient använder brandväggen som en DNS-server eller WebAdmin-destination. Det är just denna trafik som kan påverkas eftersom den slutar vid brandväggen.
• Trafik från brandväggen: Brandväggen frågar efter destinationer AD, DNS, LDAP, RADIUS, NTP eller Syslog. Detta är också viktigt eftersom brandväggen själv är avsändaren.

Om endast en applikation testas mellan två värdar kan felet inte identifieras med säkerhet. Testet måste medvetet inkludera en tjänst som slutar på Sophos Firewall eller skapas av brandväggen.

Typiska symtom

Möjliga tecken är:

• Användarbaserade regler fungerar inte längre tillförlitligt eftersom AD, STAS eller LDAP inte kan nås på ett stabilt sätt.
• DNS-frågor till brandväggen misslyckas från enskilda VLAN.
• Ping eller HTTPS på lokala brandväggstjänster fungerar inte från en VLAN, även om brandväggsreglerna ser rimliga ut.
• Övervakning eller Syslog verkar vara ofullständig om brandväggen måste nå ett mål i en taggad VLAN.
• Packet Capture visar att trafik mellan slutsystem är synlig, men brandväggstjänsterna själva svarar inte som förväntat.
• Efter en SFOS-22-uppgradering uppstår symptomen utan att medvetet ändra något på switchen eller brandväggsreglerna.

Sådana symtom bör inte omedelbart åtgärdas med breda regler eller godkännanden av enhetsåtkomst. Först måste det framgå om själva gränssnittsdesignen påverkas.

Snabb avgränsning före konvertering

Innan du flyttar en brygga IP eller skapar nya VLAN-gränssnitt på bryggan, bör du begränsa orsaken. Inte alla problem efter en uppgradering är automatiskt SFOS-22-Bridge-VLAN-fodralet.

Praktisk klassificering:

• Bara en enda applikation mellan två värdar fungerar inte: Mer sannolikt är brandväggsregel, NAT, målsystem eller returväg. Först testa brandväggsregeln och för droppar analysera tappade paket.
• WebAdmin, DNS eller ping till brandväggen från en VLAN fungerar inte: Kontrollera specialfallet Device Access, zon, lokal tjänst eller brygga VLAN. Testa sedan trafiken till brandväggen separat.
• Brandväggen når inte AD, LDAP, RADIUS, DNS eller Syslog i VLAN: Kontrollera trafik från brandväggen, routing, DNS eller bro VLAN specialfall. Använd tester direkt från brandväggskonfigurationen och lämpliga tjänsteloggar.
• Normal klienttrafik körs, men tjänster för själva brandväggen är det inte: Specialfall för Bridge VLAN blir mer sannolikt. Kontrollera bryggdesign, gamla CLI VLAN-taggkonfiguration och VLAN-gränssnitt för brygga.
• Det finns inga matchande loggposter alls: Kontrollera loggning, filter, lokal tjänst eller icke-loggad brygga/NAT specialfall. Kombinera Log Viewer, Packet Capture och relevanta Sophos Firewall tjänsteloggar.

För DNS-problem är det också viktigt om klienter använder brandväggen som en resolver eller om brandväggen själv använder DNS-begäranvägar till interna servrar. Det andra fallet gäller trafik från brandväggen och kan se annorlunda ut än normal klienttrafik för Bridge VLAN-problem. Grunderna finns i Ställa in rutter för DNS-begäran på Sophos Firewall.

Om den snabba avgränsningen tydligt pekar mot lokala brandväggstjänster eller trafik som genereras av brandväggen, bör konverteringen fortfarande planeras. En bryggkorrigering utan backup, underhållsfönster och alternativ åtkomstväg är för riskabelt för produktiva nätverk.

Inkludera befintlig design

Innan du gör ändringar bör du dokumentera aktuell status. Särskilt viktiga är:

• Namn på brygggränssnittet, till exempel br0.
• Bridge-medlemmar, d.v.s. deltagande fysiska gränssnitt, VLAN, RED-gränssnitt eller LAG.
• IP-adress för bryggan, om tillgänglig.
• VLAN ID:n som passerar över bron.
• Byt portprofil: Tagged VLAN, Native VLAN, Trunk eller åtkomstport.
• Tjänster som slutar på brandväggen: DNS, Ping, HTTPS, SSH, User Portal, VPN Portal.
• Tjänster som brandväggen måste nå: AD, LDAP, RADIUS, DNS, NTP, Syslog, Central, Monitoring.

Om strukturen kommer från en gammal migrering bör du också kontrollera om VLAN har konfigurerats via CLI-konfiguration. Det är just detta arv som ofta inte längre finns i åtanke när brandväggen bara har uppdaterats genom åren.

⚠️ Du bör inte spontant experimentera med brygggränssnitt och VLAN under den dagliga verksamheten. En felaktig ändring kan påverka hanteringsåtkomst, DNS, autentisering eller hela klientnätverk. Innan korrigeringen krävs en säkerhetskopia, ett underhållsfönster och en alternativ åtkomstväg.

Bryggspecifika fallgropar före korrigeringen

Tre bryggbegränsningar måste kontrolleras noggrant före ändringen.

För det första: en brygga utan IP-adress kan släppa trafik om trafiken matchar en brandväggsregel med web proxy filtering eller en NAT-regel. Dessa drops loggas inte. Om en NAT-regel ändå behövs måste den avgränsas så att source translation för bryggan utan IP-adress förblir Original. Annars kan man leta i Log Viewer efter ett drop som aldrig visas där.

För det andra: VLAN filtering på bryggan gäller bara bridged traffic, inte routed traffic. Om Filter VLANs är aktiverat men inga tillåtna VLAN IDs har angetts släpps taggad trafik från alla VLANs; otaggad trafik undantas. Vid testning kan detta se ut som ett inkonsekvent VLAN-problem.

För det tredje: brygggränssnitt ersätter inte varje design. Begränsningar gäller för Dynamic DNS, DHCP client, PPPoE och IPsec VPN. Om någon av dessa funktioner ingår i målbilden bör bridge-workarounden inte användas isolerat; gränssnittsdesignen bör bedömas om.

Skapa VLAN-gränssnitt som stöds

Den lösning som stöds är att skapa VLAN-gränssnitt i Network > Interfaces med bryggan som parent. Fysiska, RED-, brygg- och LAG-gränssnitt är giltiga parents.

Före SFOS 18.0 krävdes system vlan-tag för VLAN-taggad kommunikation över bryggor. Sedan SFOS 18.0 finns VLAN-over-bridge i WebAdmin. För följande CLI-kommando anges varken Device Console, Advanced Shell, menynummer, prompt eller behörighetsnivå. Använd bara den stödda CLI-kontext på brandväggen där kommandot är tillgängligt. Om det inte är tillgängligt ska du stoppa och fråga Sophos Support i stället för att gissa shell eller kontext. Kontrollera först legacy-konfigurationen med detta skrivskyddade kommando:

system vlan-tag show

Nya eller rensade designer bör inte längre bygga på system vlan-tag. Om sådana CLI-taggar fortfarande finns ska de dokumenteras, migreras till VLAN-gränssnitt i WebAdmin och först därefter ska firmwareuppgraderingen fortsätta. Detta minskar både SFOS 22 bridge-specialfallet och senare uppgraderingsblockeringar.

Exempel:

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

När VLAN skapas i WebAdmin är tre fält avgörande: Interface måste vara bridgen, Zone måste matcha VLANets säkerhetssyfte och VLAN ID måste vara unikt. WebAdmin tillåter VLAN IDs från 1 till 4094; samma VLAN ID bör inte planeras mer än en gång på samma parent interface.

Processen beror på om själva bryggan redan har en IP-adress.

Om bryggan inte behöver en IP-adress

Om bryggan bara ska vidarebefordra transparent kan den användas utan sin egen IP-adress. IP-adressen för den berörda VLAN finns sedan i VLAN-gränssnittet, till exempel br0.100.

Praktisk process:

1. Exportera en backup som dokumentation, men räkna inte med att den kan återställas som återgång i SFOS 22.
2. Dokumentera aktuell brygga och VLAN-konfiguration.
3. Välj Add interface > Add VLAN under Network > Interfaces.
4. Välj bryggan som överordnat gränssnitt, till exempel br0.
5. Ange VLAN ID.
6. Välj din zon medvetet.
7. Ställ in IP-adress på VLAN-gränssnittet om brandväggen ska finnas i denna VLAN Gateway eller lokala tjänst.
8. Kontrollera Device Access för zonen.
9. Kontrollera brandväggsregler och NAT-regler.
10. Validera ändringen med en testklient och skapa en ny backup först när testerna har lyckats.

Zonen är inte bara ordning i WebAdmin. Detta beslut påverkar brandväggsregler, Device Access, loggar och många senare felsökningssteg. Om en VLAN är avsedd som ett hanterings-, server- eller klientnätverk bör detta synas i zonen.

Om bryggan tidigare hade den produktiva IP-adressen

Om bryggan för närvarande använder IP-adressen, som måste vara tillgänglig i VLAN i framtiden, bör du vara särskilt försiktig. Det finns två rena varianter för konverteringen: Bryggan får en annan IP-adress, eller så förblir bryggan utan en IP-adress. Den tidigare produktiva adressen tilldelas sedan till VLAN-gränssnittet.

Detta är en förändring med risk för misslyckande. Det bör förtydligas i förväg:

• Vilken adress används för att nå WebAdmin?
• Vilka klienter använder brandväggen som standard Gateway?
• Vilka DNS- eller DHCP-inställningar pekar på den här adressen?
• Vilka regler för enhetsåtkomst gäller för den tidigare zonen?
• Finns det en andra hanteringsåtkomst från ett opåverkat nätverk?

För avlägsna platser bör denna förändring inte planeras utan en lokal returväg. Om WebAdmin och SSH kör över exakt den påverkade bryggan IP, kan ett fel avbryta administrativ åtkomst.

Ta bort legacy-konfigurationen och förbered uppgraderingen

Skapa först alla nödvändiga VLAN-gränssnitt i Network > Interfaces med bryggan som parent, flytta vid behov bryggans IP till rätt VLAN-gränssnitt och validera data- och hanteringsvägar. I HA ska du via det stödda statusgränssnittet bekräfta att peer och synkronisering är friska och säkerhetskopiera varje nod när plattformen och supportproceduren kräver det. Om status är felaktig eller oklar ska du stoppa före reset eller uppgradering och eskalera; hitta inte på HA- eller synkroniseringskommandon. Med dokumenterad mappning, aktiv alternativ åtkomst och uppfyllda HA-krav tar du bort inställningen i samma stödda CLI-kontext som beskrivs ovan:

system vlan-tag reset

Kör system vlan-tag show igen. Om konfiguration återstår, reset misslyckas eller resultatet är oklart ska du stoppa: starta inte uppgraderingen och godkänn inte den nya backupen som en rensad punkt. Spara utdata, precheck och konfiguration och eskalera till Sophos Support utan odokumenterade kommandon. Det finns ingen dokumenterad återgång på kommandonivå för system vlan-tag reset: godkända kontroller verifierar rensningen, inte återgången. Återskapa inte legacy-inställningen med ett antaget kommando efter reset. Om ändringen måste tas tillbaka ska du stoppa och eskalera för en leverantörsgodkänd återställning på den ursprungliga stödda firmwareversionen. Efter godkända tester skapar du en ny backup, kör precheck igen och uppgraderar först därefter. För en återställningsbar backup rensar du källbrandväggen på samma sätt, skapar vid behov VLAN-gränssnittet, validerar och tar sedan backupen. Detta reparerar inte en gammal backup med system vlan-tag.

Device Access och kontrollera brandväggsreglerna efteråt

Efter att ha skapat VLAN-gränssnittet räcker det inte att bara testa IP-adressen. Device Access och brandväggsregler måste matcha det nya gränssnittet och zondesignen.

För att kontrollera:

• Administration > Device access: Är portalen Ping/Ping6, DNS, HTTPS, SSH, User Portal eller VPN endast tillåtna i rätt zoner?
• Rules and policies > Firewall rules: Finns det regler för den nya zonen?
• Rules and policies > NAT rules: Översätts trafiken oväntat?
• Network > DNS eller DNS-begäranvägar: når brandväggen rätt DNS- eller AD-servrar?
• Authentication > Servers: Är AD, LDAP eller RADIUS tillgängliga efter ändringen? För lokala brandväggstjänster är Device Access säkert konfigurera Sophos Firewall den lämpliga djupgående artikeln. Sophos Firewall Testregel med Log Viewer och Packet Capture hjälper till med regelanalys.

Validering efter korrigering

Ett rent test bör innehålla mer än en ping.

Testa från den drabbade VLAN

Check från en klient i den berörda VLAN:

1. Nå standard Gateway.
2. Testa brandväggen IP på det nya VLAN-gränssnittet via ping, om tillåtet.
3. Testa DNS mot brandväggen om brandväggen fungerar som en DNS-resolver.
4. Testa WebAdmin eller portal endast från tillåtna hanteringsnätverk.
5. Kontrollera en typisk applikation eller serveranslutning.
6. Kontrollera Log Viewer för matchande regel-ID och zon.

Testa från brandväggen

Separata tester krävs för trafik som brandväggen själv genererar:

• Testa AD eller LDAP servrar i Authentication > Servers.
• Kontrollera DNS-upplösningen via brandväggen.
• Kontrollera NTP, Syslog eller övervakningsmål om dessa tjänster finns i VLAN.
• Kontrollera VLAN-gränssnittet under Diagnostics > Packet capture. Generated markerar paket som brandväggen skapar och Consumed paket som är avsedda för den; jämför även In interface, Out interface, Rule ID, Status och Reason.

Om STAS eller användarbaserade regler påverkas, bör Set up STAS on Sophos Firewall också kontrolleras. För SFOS-22 uppgraderingar hör denna punkt också till i SFOS 22 uppgraderingskontrollen.

Återgång och avslut

Anteckna före ändringen bryggans IP-adress och zon, VLAN-ID:n, switchportprofil samt beroende regler och tjänster. Förbered en alternativ eller lokal hanteringsväg och en leverantörsgodkänd återställningsplan. Före system vlan-tag reset kan planerade WebAdmin-ändringar tas tillbaka i dokumenterad ordning: ta först bort en flyttad IP från VLAN-gränssnittet och tilldela den sedan till bryggan; återställ zon, regler, Device Access och switchportprofil och kontrollera anslutningen. Detta upphäver inte reset. Efter reset finns ingen dokumenterad återgång på kommandonivå: stoppa vid misslyckad verifiering och eskalera för godkänd återställning på den ursprungliga stödda firmwareversionen. I HA får ingen nod återställas eller uppgraderas när peer eller synkronisering är felaktig eller oklar; behåll tillämplig backup för varje nod.

Skapa en ny backup efter godkänd verifiering. Den gamla backupen med legacy CLI VLAN tagging är ingen återgångsväg för SFOS 22.0 GA eller senare. Om precheck fortfarande rapporterar konfigurationen sparar du konfigurationen och meddelandet och kontaktar Sophos Support i stället för att prova fler odokumenterade CLI-ändringar.

Vanliga fel

Typiska fallgropar:

• Test endast klient-till-server-trafik: Bryggan verkar vara frisk, även om lokala brandväggstjänster påverkas. Testa även trafik till och från brandväggen.
• Flytta bryggan IP utan plan: WebAdmin, DNS eller Gateway kan misslyckas. Förbered backup, underhållsfönster och alternativ åtkomst.
• Välj zon felaktigt för det nya VLAN-gränssnittet: Regler, Device Access och loggar passar inte. Välj en zon baserat på säkerhetssyften, inte baserat på vana.
• Device Access öppen för vid: Problemet verkar löst, men hanteringstjänster är onödigt tillgängliga. Local Service ACL plan specifikt.
• Kontrollera inte switchporten: VLAN anländer felaktigt eller omärkt. Validera profilen Tagged/Untagged, Native VLAN och Trunk.
• Ignorera gammal CLI-konfiguration: Felet förblir oförklarat efter uppgraderingen. Dokumentera gammal design och migrera till WebAdmin-VLAN gränssnitt.

Checklista

• SFOS-version och känd problemrelevans kontrollerad.
• Bridge-gränssnitt, bryggmedlemmar och VLAN-ID:n dokumenterade.
• Klargjort om den gamla CLI VLAN-taggkonfigurationen användes.
• Bryggspecifika NAT/web proxy drops och VLAN filtering kontrollerade.
• Planerad uppgradering till SFOS 22.0 MR2 eller senare kontrollerad mot legacy CLI VLAN tags.
• Berörda tjänster till och från brandväggen identifierade.
• Backup för varje tillämplig nod och alternativ hanteringsåtkomst tillgängliga; HA-peer och synkronisering friska.
• VLAN-gränssnitt planerat med brygga som överordnat gränssnitt.
• Zon, Device Access, brandväggsregler och NAT regler har markerats.
• Tester utförda från VLAN och från brandväggen.
• Återställningsgränsen dokumenterad: ingen dokumenterad återgång för system vlan-tag reset; ny backup skapad efter korrigeringen.
• Resultat registrerat i ändringsloggen eller i nätverksdokumentationen.

Vanliga frågor