Kontrollera Sophos Firewall Bridge-VLANs efter SFOS 22

Bridge-gränssnitt på Sophos Firewall är praktiska när ett befintligt lager-2-nätverk ska fortsätta transparent eller en migrering ska genomföras utan omedelbara IP-ändringar. Med VLANs på en bridge blir designen dock snabbt felbenägen: Det finns 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 det en viktig driftsituation med SFOS 22. Sophos listar i den aktuella listan över kända problem ett problem där Bridge-gränssnitt med CLI VLAN tag-konfigurationer i SFOS 22.0 GA och SFOS 22.0 MR1 inte korrekt hanterar VLAN-taggad trafik när denna trafik kommer från Sophos Firewall själv eller slutar på brandväggen. Detta kan till exempel påverka Active Directory, DNS, Device Access, STAS, LDAP, RADIUS eller hanteringsåtkomst, även om normal trafik vidarebefordras genom bridgen.

Denna artikel är inte ett allmänt kapitel om VLAN-grunder. För planering av zoner, gränssnitt, VLANs, bridges och LAGs, se först Konfigurera Sophos Firewall zoner och gränssnitt. Här fokuserar vi specifikt på bridge-VLAN-specialfallet efter SFOS 22.

När detta ämne är relevant

Kontrollen är meningsfull när flera punkter sammanfaller:

• Brandväggen körs på SFOS 22.0 GA eller SFOS 22.0 MR1.
• Det finns ett bridge-gränssnitt, till exempel br0.
• VLANs har historiskt byggts med CLI VLAN tag-konfiguration som system vlan-tag eller tagits över från en gammal konfiguration.
• Brandväggens egna tjänster måste nå ett taggat VLAN.
• Efter en uppgradering fungerar AD, DNS, autentisering, övervakning eller hanteringsåtkomst endast delvis.
• Normal klienttrafik genom bridgen verkar fortsätta fungera.

Den sista punkten är viktig: Om bridgen fortfarande vidarebefordrar trafik mellan nätverk verkar problemet först inte som ett bridge-fel. I praktiken söker man då snabbt på fel ställe, till exempel vid brandväggsregler, DNS, STAS eller domänkontrollanten.

Förstå den påverkade trafikriktningen

Man måste tydligt skilja mellan tre typer av trafik.

Om endast en applikation mellan två värdar testas, upptäcker man därför inte felet säkert. Testet måste medvetet inkludera en tjänst som slutar på Sophos Firewall eller genereras av brandväggen.

Typiska symptom

Möjliga tecken är:

• Användarbaserade regler fungerar inte längre pålitligt eftersom AD, STAS eller LDAP inte är stabilt tillgängliga.
• DNS-förfrågningar till brandväggen misslyckas från enskilda VLANs.
• Ping eller HTTPS till lokala brandväggstjänster fungerar inte från ett VLAN, även om brandväggsreglerna verkar rimliga.
• Övervakning eller Syslog verkar ofullständig när brandväggen måste nå ett mål i ett taggat VLAN.
• Packet Capture visar att trafik mellan slutsystem är synlig, men brandväggens egna tjänster svarar inte som förväntat.
• Efter en SFOS-22-uppgradering uppstår symptomen utan att något medvetet ändrats på switchen eller brandväggsreglerna.

Sådana symptom bör inte omedelbart besvaras med breda tillåtelse-regler eller Device Access-tillstånd. Först måste det vara klart om gränssnittsdesignen själv är påverkad.

Snabb avgränsning innan ombyggnad

Innan man flyttar en bridge-IP eller skapar nya VLAN-gränssnitt på bridgen, bör man avgränsa orsaken. Inte varje problem efter en uppgradering är automatiskt SFOS-22-bridge-VLAN-fallet.

För DNS-problem är det dessutom viktigt om klienter använder brandväggen som resolver eller om brandväggen själv använder DNS Request Routes till interna servrar. Det andra fallet påverkar trafik från brandväggen och kan se annorlunda ut vid bridge-VLAN-problem än normal klienttrafik. Grunderna finns i Ställ in DNS Request Routes på Sophos Firewall.

Om snabb avgränsning tydligt pekar på lokala brandväggstjänster eller trafik genererad av brandväggen, bör ombyggnaden ändå planeras. En bridge-korrigering utan backup, underhållsfönster och alternativ åtkomstväg är för riskabelt i produktiva nätverk.

Dokumentera befintlig design

Innan ändringar bör man dokumentera det aktuella tillståndet. Särskilt viktigt är:

• Namn på bridge-gränssnittet, till exempel br0.
• Bridge-medlemmar, alltså deltagande fysiska gränssnitt, VLANs, RED-gränssnitt eller LAGs.
• IP-adress för bridgen, om sådan finns.
• VLAN-ID:n som går över bridgen.
• Switch-portprofil: Taggade VLANs, Native VLAN, Trunk eller Access Port.
• 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, övervakning.

Om uppbyggnaden kommer från en gammal migrering bör man dessutom kontrollera om VLANs konfigurerades via CLI. Just denna gamla konfiguration är ofta inte längre i åtanke när brandväggen bara har uppdaterats under åren.

⚠️ Man bör inte experimentera spontant med bridge-gränssnitt och VLANs under daglig drift. En felaktig ändring kan påverka hanteringsåtkomst, DNS, autentisering eller hela klientnätverk. Innan korrigeringen behövs en backup, ett underhållsfönster och en alternativ åtkomstväg.

Workaround: Skapa VLAN-gränssnitt på bridgen

Ett praktiskt sätt är att skapa VLAN-gränssnitt i Network > Interfaces och använda bridge-gränssnittet som Parent Interface.

Exempel:

Förfarandet beror på om bridgen själv redan har en IP-adress.

Om bridgen inte behöver en IP-adress

Om bridgen bara ska vidarebefordra transparent kan den köras utan egen IP-adress. IP-adressen för det berörda VLAN ligger då på VLAN-gränssnittet, till exempel br0.100.

Praktiskt förfarande:

1. Skapa backup.
2. Dokumentera aktuell bridge- och VLAN-konfiguration.
3. Lägg till ett nytt VLAN-gränssnitt under Network > Interfaces.
4. Välj bridgen som Parent Interface, till exempel br0.
5. Ange VLAN-ID.
6. Välj zon medvetet.
7. Sätt IP-adress på VLAN-gränssnittet om brandväggen ska vara gateway eller lokal tjänst i detta VLAN.
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 ett VLAN är tänkt som hanterings-, server- eller klientnätverk bör det synas i zonen.

Om bridgen tidigare hade den produktiva IP-adressen

Om bridgen för närvarande använder IP-adressen som i framtiden måste vara tillgänglig i VLAN, bör man gå försiktigt fram. För ombyggnaden finns två rena varianter: Bridgen får en annan IP-adress, eller bridgen förblir utan IP-adress. Den tidigare produktiva adressen tilldelas sedan VLAN-gränssnittet.

Detta är en förändring med risk för avbrott. Innan bör det klargöras:

• Vilken adress används för att nå WebAdmin?
• Vilka klienter använder brandväggen som standardgateway?
• Vilka DNS- eller DHCP-inställningar pekar på denna adress?
• Vilka Device Access-regler är kopplade till den tidigare zonen?
• Finns det en andra hanteringsåtkomst från ett icke-påverkat nätverk?

Vid fjärrplatser bör denna ändring inte planeras utan lokal återgångsväg. Om WebAdmin och SSH körs över just den berörda bridge-IP:n kan ett fel avbryta administrativ åtkomst.

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 passa det nya gränssnitts- och zonedesignen.

Att kontrollera:

• Administration > Device access: Är Ping/Ping6, DNS, HTTPS, SSH, User Portal eller 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 trafik oväntat?
• Network > DNS eller DNS Request Routes: Når brandväggen rätt DNS- eller AD-servrar?
• Authentication > Servers: Är AD, LDAP eller RADIUS tillgängliga efter omställningen?

För lokala brandväggstjänster är Konfigurera Device Access på Sophos Firewall säkert den lämpliga fördjupningsartikeln. För regelanalys hjälper Testa Sophos Firewall-regel med Log Viewer och Packet Capture.

Validering efter korrigeringen

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

Test från det berörda VLAN

Från en klient i det berörda VLAN, kontrollera:

1. Nå standardgateway.
2. Testa brandväggens IP på det nya VLAN-gränssnittet med ping, om tillåtet.
3. Testa DNS mot brandväggen om brandväggen fungerar som 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 lämplig regel-ID och zon.

Test från brandväggen

För trafik som brandväggen själv genererar behövs separata tester:

• Testa AD- eller LDAP-server i Authentication > Servers.
• Kontrollera DNS-upplösning via brandväggen.
• Kontrollera NTP, Syslog eller övervakningsmål om dessa tjänster ligger i VLAN.
• Använd Packet Capture på VLAN-gränssnittet om det är oklart om paket lämnar brandväggen.

Om STAS eller användarbaserade regler påverkas bör dessutom Ställ in STAS på Sophos Firewall kontrolleras. Vid SFOS-22-uppgraderingar hör denna punkt också till SFOS 22 Upgrade Check.

Vanliga fel

Checklista

• SFOS-version och känd problemrelevans kontrollerad.
• Bridge-gränssnitt, bridge-medlemmar och VLAN-ID:n dokumenterade.
• Klart om gammal CLI VLAN tag-konfiguration användes.
• Identifierade påverkade tjänster till och från brandväggen.
• Backup och alternativ hanteringsåtkomst tillgänglig.
• VLAN-gränssnitt med bridge som Parent Interface planerat.
• Zon, Device Access, brandväggsregler och NAT-regler kontrollerade.
• Tester från VLAN och från brandväggen genomförda.
• Resultat dokumenterat i ändringslogg eller nätverksdokumentation.

FAQ