Sophos Firewall Kontrollera brygg-VLAN för SFOS 22

Brygggränssnitt på Sophos Firewall är praktiska om ett befintligt Layer 2-nätverk ska fortsätta transparent eller en migrering ska implementeras utan omedelbara IP-ändringar. Men med VLAN på en brygga blir designen snabbt felbenägen: Det sker då vidarebefordran mellan nätverk, trafik till själva brandväggen, Device Access, DNS, AD, autentisering och ofta gamla CLI-konfigurationer.

Just här finns ett viktigt driftsfall med SFOS 22. Sophos listar ett problem i den aktuella listan över kända problem där bridge interfaces med CLI VLAN-taggningskonfigurationer i SFOS 22.0 GA och SFOS 22.0 MR1 inte hanterar trafiken från rätt VLAN om trafiken kommer från själva brandväggen eller avslutas på brandväggen. Detta kan till exempel påverka Active Directory, DNS, Device Access, STAS, LDAP, RADIUS eller hanteringsåtkomst, även om normal trafik routas genom bryggan.

Sophos beskriver nu också legacy CLI VLAN tagging som deprecated. Sådana äldre konfigurationer kan förhindra uppgraderingar till SFOS 22.0 MR2 och senare versioner. Kontrollen är därför inte bara felsökning efter en uppgradering, utan också en användbar förberedelse inför nästa underhållsfönster.

Den här artikeln är inte ett allmänt kapitel om VLAN grunder. För planering av zoner, gränssnitt, VLAN, bryggor och LAG:er passar Sophos Firewall Konfigurera zoner och gränssnitt först. Det här handlar specifikt om bryggan VLAN specialfall 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

Sophos beskriver tre bryggbegränsningar som bör kontrolleras medvetet 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. Enligt Sophos loggas dessa drops 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. Sophos listar begränsningar 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.

Lösning och uppgraderingsförberedelse

Ett praktiskt sätt är att skapa VLAN-gränssnitt i Network > Interfaces med brygggränssnittet som överordnat gränssnitt.

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. Sophos tillåter WebAdmin 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. Skapa säkerhetskopia.
2. Dokumentera aktuell brygga och VLAN-konfiguration.
3. Lägg till ett nytt VLAN-gränssnitt 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 med en testklient.

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.

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.
• Använd Packet Capture på VLAN-gränssnittet när det är oklart om paket lämnar brandväggen.

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.

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.
• Säkerhetskopiering och alternativ hanteringsåtkomst tillgänglig.
• 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.
• Resultat registrerat i ändringsloggen eller i nätverksdokumentationen.

Vanliga frågor