Ersätt äldre VLAN-taggning på bryggor 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, kontrollera uppgraderingsvägen och tillämpliga blockerare separat för den builden 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äggens egna tjänster måste kunna nå ett taggat VLAN.
• Efter en uppgradering fungerar AD, DNS, autentisering, övervakning eller hanteringsåtkomst endast delvis.
• Normal klienttrafik genom bryggan verkar fortfarande fungera.
• En uppgradering till SFOS 22.0 MR2 eller senare är planerad eller blockeras av legacy CLI VLAN tagging.

Punkten om klienttrafiken är viktig: om bryggan fortsätter att vidarebefordra trafik mellan nätverk verkar problemet till en början inte vara ett bryggfel. 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

Skilj mellan tre typer av trafik:

• Trafik som vidarebefordras 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 ett taggat 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 specialfallet med brygg-VLAN i SFOS 22.

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 fungerar, men brandväggens egna tjänster fungerar 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.

Dokumentera den befintliga designen

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.
• Switchportens profil: 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 kassera 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 kasseras taggad trafik från alla VLAN; 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 att aktivera VLAN-taggad kommunikation över brygggränssnitt. Sedan SFOS 18.0 är VLAN-over-bridge fullt tillgängligt i WebAdmin. Vid inventering och rensning måste dock en viktig begränsning beaktas: dokumentationen för VLAN-taggar i SFOS 22 och 23 beskriver en reset med gränssnittsargument samtidigt som den anger att konfigurationen visas. Detta belägger varken att ett fristående system vlan-tag show är en fråga som inte ändrar konfigurationen eller att system vlan-tag reset utan argument är ett rensningskommando med känt tillämpningsområde. Att ett kommando är tillgängligt i en CLI-kontext bekräftar inte heller dessa egenskaper.

Före varje CLI-åtgärd för inventering eller rensning måste entydig dokumentation för den installerade builden eller Sophos Support bekräfta exakt vilken metod som inventerar konfigurationen utan att ändra den och vilken syntax som gäller för rensningen. Detta omfattar den exakta CLI-kontexten, nödvändiga behörigheter och argument, berörda gränssnitt respektive noder samt rensningens effekter och tillämpningsområde. Om dessa punkter inte har klarlagts ska endast den konfiguration som är synlig i WebAdmin under Network > Interfaces dokumenteras, och arbetet ska stoppas före rensning eller uppgradering. Att poster saknas i WebAdmin bevisar inte att det saknas äldre CLI-taggar; klargör den öppna inventeringsfrågan med Sophos Support i stället för att prova ett förmodat visnings- eller reset-kommando.

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. Ange IP-adressen på VLAN-gränssnittet om brandväggen ska fungera som gateway eller tillhandahålla en lokal tjänst i detta VLAN.
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 ändring med risk för driftavbrott. 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 bryggans IP-adress, kan ett fel avbryta administrativ åtkomst.

Ta bort legacy-konfigurationen och förbered uppgraderingen

Ordningen är avgörande: efter klargörandet ovan ska du först skapa alla nödvändiga VLAN-gränssnitt i Network > Interfaces med bryggan som Parent Interface, vid behov flytta bryggans befintliga IP-adress till rätt VLAN-gränssnitt och kontrollera de nya vägarna för data- och hanteringstrafik. I en HA-miljö ska du dessförinnan använda den stödda statusvisningen för att säkerställa att peer-noden och synkroniseringen är felfria, och säkerhetskopiera varje nod i den utsträckning som plattformen och supportförfarandet föreskriver. Om peer- eller synkroniseringsstatusen är felaktig eller oklar ska du stoppa före rensning eller uppgradering och eskalera ärendet. Hitta inte på något HA- eller synkroniseringskommando.

Först när mappningen är dokumenterad, en alternativ åtkomstväg är aktiv och alla HA-förutsättningar är uppfyllda får den äldre inställningen tas bort med det förfarande som har bekräftats för den installerade builden genom dokumentation eller av Sophos Support. Bekräftelsen av exakt syntax, CLI-kontext, effekter och tillämpningsområde för gränssnitt och noder måste finnas före körningen; den här artikeln ger inte ett ovillkorligt klartecken att köra ett reset-kommando. Om bekräftelsen saknas ska du begränsa dig till inventering i WebAdmin och stoppa före rensning eller uppgradering.

Kontrollera därefter specifikt om den äldre inställningen har tagits bort inom det avsedda tillämpningsområdet, med den inventeringsmetod som tidigare har bekräftats inte ändra konfigurationen. Trafiktester ensamma bevisar inte detta. Om en äldre konfiguration fortfarande är synlig, rensningen misslyckas eller inventeringsresultatet är oklart ska du stoppa arbetet: starta inte uppgraderingen ännu och godkänn inte den nya säkerhetskopian som en rensad återställningspunkt. Spara befintliga inventeringsunderlag, eventuell kommandoutdata, resultatet av förkontrollen inför uppgradering och den aktuella konfigurationen, och eskalera till Sophos Support; prova inga odokumenterade CLI-kommandon.

Den motsägelsefulla beskrivningen av reset ger inte heller stöd för en tillförlitlig återgång på kommandonivå. Lyckade inventeringskontroller och trafiktester bekräftar rensningen, inte återgångsmöjligheten. Återskapa inte den äldre inställningen med ett gissat kommando efter rensningen. Om ändringen måste återtas ska du stoppa och involvera Sophos Support för en tillverkargodkänd återställning på den ursprungliga firmwareversionen som stöds; återta WebAdmin-ändringar endast inom ramen för denna godkända plan.

När acceptanstesterna och den förnyade inventeringskontrollen har lyckats ska du skapa en ny säkerhetskopia, upprepa förkontrollen inför uppgradering och först därefter uppgradera till SFOS 22.0 MR2 eller senare. Samma bekräftade rensningsförfarande gäller för att skapa ett tillstånd som kan återställas framöver: ta bort den äldre inställningen på källbrandväggen, skapa vid behov ett VLAN-gränssnitt med bryggan som Parent, kontrollera och skapa först därefter en ny säkerhetskopia. Detta reparerar inte en gammal säkerhetskopia med system vlan-tag.

Kontrollera Device Access och brandväggsregler 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 Ping/Ping6, DNS, HTTPS, SSH, User Portal och VPN Portal 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 Konfigurera Device Access säkert på Sophos Firewall den lämpliga djupgående artikeln. Testa en Sophos Firewall-regel 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 det berörda VLAN:et

Kontrollera följande från en klient i det berörda VLAN:et:

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 Konfigurera STAS på Sophos Firewall också kontrolleras. För SFOS-22 uppgraderingar hör denna punkt också till i SFOS 22 uppgraderingskontrollen.

Återgång och avslut

Före ändringen ska bryggans befintliga IP-adress, zon, VLAN-ID:n, switchportkonfiguration samt beroende regler och tjänster dokumenteras. Dessutom krävs alternativ eller lokal hanteringsåtkomst och en tillverkargodkänd återställningsplan. Så länge den bekräftade CLI-rensningen ännu inte har utförts kan planerade WebAdmin-ändringar återtas i dokumenterad ordning: ta först bort en flyttad IP-adress från det nya VLAN-gränssnittet och tilldela den först därefter till bryggan igen; återställ sedan zon, regler, Device Access och switchportprofil och kontrollera att hanteringsåtkomsten och gatewayen är nåbara. Detta upphäver inte en CLI-rensning.

Den motsägelsefulla beskrivningen av reset belägger inte någon återgång på kommandonivå. Om acceptanstesterna misslyckas efter den bekräftade rensningen ska du stoppa och inte återskapa den äldre inställningen. Eskalera för en tillverkargodkänd återställning på den ursprungliga firmwareversionen som stöds. Vid HA får inga noder rensas eller uppgraderas så länge peer- eller synkroniseringsstatusen är felaktig eller oklar; behåll den säkerhetskopia som krävs för varje nod. Utan den förhandsbekräftelse som krävs av inventeringsmetod, rensningssyntax, kontext, effekter och tillämpningsområde ska arbetet begränsas till inventering i WebAdmin och stoppas före rensning eller uppgradering.

Efter lyckade acceptanstester skapas en ny säkerhetskopia. Den gamla säkerhetskopian med Legacy CLI VLAN tagging är ingen återgångsväg för SFOS 22.0 GA eller senare. Om den äldre konfigurationen finns kvar trots migreringen i WebAdmin eller fortfarande rapporteras av förkontrollen inför uppgradering ska du inte experimentera med fler CLI-ändringar, utan spara konfigurationen och meddelandet och involvera Sophos Support.

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 bryggans IP-adress 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. Planera Local Service ACL för det specifika behovet.
• 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 kontrollerats.
• Tester utförda från VLAN och från brandväggen.
• Inventeringsmetod som inte ändrar konfigurationen samt exakt rensningssyntax, CLI-kontext, effekter och tillämpningsområde bekräftade för den installerade builden genom dokumentation eller av Sophos Support före varje CLI-åtgärd; annars endast inventering i WebAdmin och stopp före rensning eller uppgradering.
• Återställningsgräns dokumenterad: den motsägelsefulla beskrivningen av reset ger inte stöd för någon återgång på kommandonivå; ny säkerhetskopia skapad efter bekräftad rensning och lyckade acceptanstester.
• Resultat registrerat i ändringsloggen eller i nätverksdokumentationen.

Vanliga frågor