Sophos Firewall Konfigurera zoner och gränssnitt

Zoner och gränssnitt är bland de viktigaste grunderna i en Sophos Firewall. Om du planerar dem noggrant kommer du att göra senare brandväggsregler, NAT, VPN, webbskydd och felsökning mycket enklare. Om du klickar ihop dem för snabbt skapar du ofta en miljö där regler blir förvirrande eller hanteringstjänster är tillgängliga på fel ställen.

En Zone är en logisk säkerhetsgrupp. Ett Gränssnitt är en fysisk eller virtuell anslutning, till exempel Port1, ett VLAN, en Bridge, en LAG, ett Alias, ett RED-gränssnitt eller ett XFRM-gränssnitt för ruttbaserad VPN. Varje gränssnitt är tilldelat exakt en zon. Brandväggsregler kommer senare att arbeta hårt med dessa zoner, så zonstrukturen bör inte bara planeras tekniskt utan även säkerhetsmässigt.

Vilken nätverksdesignartikel passar?

Zoner och gränssnitt är ofta utgångspunkten, men inte alltid själva målet med konfigurationen. Beroende på uppgiften passar en mer specifik artikel bättre:

• Planera i grund och botten zoner, gränssnitt, VLAN, broar, LAG eller RED: Denna artikel.
• Konfigurera VLAN-gränssnitt med föräldragränssnitt, DHCP, Device Access och regler: Sophos Firewall Konfigurera och testa VLAN.
• Skapa och förstå brandväggsregler mellan zoner: Förstå och korrekt konfigurera Sophos Firewall-regler.
• Kontrollera VLAN-bryggans beteende enligt SFOS 22: Sophos Firewall Använd brygga med VLAN-taggning.
• Säker hanteringstjänster som WebAdmin, SSH, User Portal eller DNS: Sophos Firewall Säker åtkomst: Konfigurera Device Access korrekt.
• Klassificera NAT, SNAT, DNAT eller MASQ med gränssnitt och zoner: Förstå NAT på Sophos Firewall: SNAT, DNAT, MASQ, PAT.
• Publicera intern server över WAN eller DMZ: Publicera server via DNAT till Sophos Firewall.
• Kontrollera DNS för interna domäner eller AD-zoner: Ställ in rutter för DNS-begäran till Sophos Firewall.
• Ställ in DHCP-alternativ för VoIP, PXE eller speciella klienter: Konfigurera DHCP-alternativ till Sophos Firewall.
• Planera plats-till-plats-VPN med tunnelgränssnitt: Sophos Firewall Konfigurera plats-till-plats IPsec VPN.
• Trafiken kommer inte genom den förväntade zonen eller regeln: Sophos Firewall Regeln gäller inte: Kontrollera orsakerna.Denna separation förhindrar typiska designfel. En zon ersätter inte en brandväggsregel, ett VLAN ersätter inte ett säkerhetskoncept och Device Access är inte detsamma som normal trafik mellan två nätverk. Först bör det framgå vilka säkerhetsområden som finns. Gränssnitt, VLAN, regler, NAT, DNS och hanteringsåtkomst byggs sedan därefter.

Varför zoner är viktiga

Zoner på Sophos Firewall är mer än bara en visuell gruppering. Detta definierar säkerhetsområden som används på flera ställen:

• Brandväggsregler fungerar med Källzon och Destinationszon.
• Device Access styr vilka lokala brandväggstjänster som är tillgängliga per zon.
• NAT, SD-WAN, VPN, webbskydd och loggar görs lättare att förstå genom rena zoner. – Felsökningen blir tydligare eftersom man direkt kan se vilket säkerhetsområde ett paket kommer ifrån och vart det ska ta vägen.

Bra zonindelning förhindrar inte automatiskt varje fel, men det tvingar fram tydliga gränser. Ett klientnätverk, ett servernätverk, ett gäst-WiFi och en DMZ bör inte bara behandlas som ett “LAN” om de har olika risker och regler. Annars kommer stora tillåtelseregler, oklara undantag och onödigt öppen hanteringsåtkomst att uppstå senare.

Bra zoner svarar alltid på denna fråga: Vilka nätverk har samma förtroendenivå och kan behandlas på samma sätt? Om två nätverk behöver olika åtkomsträttigheter, loggningskrav eller hanteringsåtkomst är en separat zon eller åtminstone ett mycket medvetet regelkoncept vettigt.

Det är viktigt att skilja mellan zon och nätverksobjekt. Zonen beskriver via vilket säkerhetsområde ett paket kommer in i firewall eller vart det ska gå. Nätverksobjektet beskriver den konkreta IP-källan eller det konkreta målet. En regel blir ren först när båda stämmer: Source zone får inte bara vara ett grovt LAN medan Source networks and devices står kvar på Any. Omvänt hjälper ett korrekt nätverksobjekt lite om trafiken kommer in via en annan zon än väntat.

Förstå standardzoner

Sophos Firewall kommer med flera standardzoner:

• LAN: Interna nätverk, klienter, servrar och hanteringsnätverk.
• WAN: Internetupplänkar, leverantörsroutrar, PPPoE, DHCP eller statiska WAN-adresser.
• DMZ: Allmänt tillgängliga servrar, omvända proxyservrar och isolerade tjänster.
• WiFi: Wi-Fi-nätverk, Sophos Access Points och trådlösa segment.
• VPN: Remote Access VPN, plats-till-plats VPN och andra tunnelsammanhang.

Standardzonerna finns under Network > Zones. Anpassade zoner kan skapas som typ LAN eller DMZ. Ytterligare WAN- eller VPN-zoner kan inte helt enkelt skapas fritt eftersom dessa zontyper har speciella funktioner i brandväggen.

Viktigt: En zon är inte en automatisk behörighet. Beroende på riktning och scenario krävs även lämpliga brandväggsregler mellan två gränssnitt i samma zon. Trafik mellan två LAN-zongränssnitt tillåts inte automatiskt, men kräver en lämplig LAN-till-LAN-regel.

Sophos Firewall stöder egna zoner, men inte som en obegränsad ersättning för rena regler. Den officiella gränsen är maximalt 100 zoner. I praktiken bör den gränsen inte pressas. Om nästan varje VLAN får en egen zon trots att många behöver identiska regler och samma Device Access blir regelverket ofta svårare att underhålla, inte säkrare.

Planera zoner innan du skapar

Innan du installerar bör du notera vilka nätverk som har olika säkerhetskrav. Typiska exempel:

• Arbetsplats LAN
• Servernätverk
• Ledningsnätverk
• DMZ
• Gäst-WiFi
• VoIP
• Kamera eller IoT-nätverk
• Produktionsnätverk
• VPN-klienter
• MPLS eller platsanslutningar

En separat zon är vettig om ett nätverk behöver sina egna regler, sin egen Device Access eller en annan nivå av förtroende. Flera VLAN kan dock också vara i samma zon om de ska behandlas lika. För många zoner gör inte automatiskt en konfiguration säkrare. Zoner är bara till hjälp om det finns tydliga regler bakom dem.

För många små och medelstora miljöer är denna grundläggande struktur en bra början:

• LAN eller Client: normala arbetsstationsklienter.
• Server: interna servrar, NAS, applikationsservrar och domänkontrollanter.
• Management: Admin-datorer, övervakning, säkerhetskopiering, switch- och brandväggshantering.
• Guest eller WiFi: Gäst-WiFi eller BYOD-nätverk med begränsad åtkomst.
• DMZ: System som måste vara tillgängliga från Internet eller från flera nätverk.
• WAN: Internet- och leverantörsanslutningar.
• VPN: Remote Access VPN eller plats-till-plats VPN-kontexter.

Alla VLAN behöver inte automatiskt sin egen zon. Om flera klient-VLAN får exakt samma brandväggsregler, webbpolicy och Device Access kan de stanna i en gemensam klientzon. Men om ett VLAN tillåts nå servrar, ett annat bara tillåts åtkomst till Internet och ett tredje inte alls ska ha tillgång till lokala brandväggstjänster, bör separationen modelleras medvetet.

Ett bra mönster är:

• Annan förtroendenivå: Kontrollera din egen zon.
• Egen hanteringsåtkomst till brandväggen: kontrollera din egen zon eller din egen ACL-regel.
• Andra loggning eller andra skyddsfunktioner: egen zon kan vara användbar.
• Endast olika IP-intervall, men samma säkerhetspolicy: gemensamt zonkoncept kan räcka.

Översätt zonmodell till en åtkomstmatris

Efter zonplanering bör du kort bestämma vilken zon som får prata med vilken annan zon. Denna åtkomstmatris är ofta mer användbar än att omedelbart skapa regler i WebAdmin eftersom den gör motsägelser synliga.

Ett enkelt exempel:

• Client till WAN: Tillåtet för webb, DNS, NTP och nödvändiga applikationer.
• Client till Server: Endast definierade applikationsportar, inte Any.
• Guest till WAN: Tillåtet, mestadels med webbpolicy och loggning.
• Guest till Server: Normalt blockerad.
• IoT till Server: Endast till exakt definierade tjänster, till exempel MQTT, DNS eller NTP.
• Management till LAN, Server, DMZ: Administrativ åtkomst, tätt och loggat.
• DMZ till LAN: Blockerad som standard, tillåt endast explicita returanslutningar.
• VPN till Server: Endast obligatoriska interna mål och tjänster.

Matrisen behöver inte vara stor. Det viktiga är att varje tillåten riktning har ett syfte. Om en post inte kan förklaras bör den inte uppstå som en bred brandväggsregel.

För varje rad bör du också notera:

• nödvändiga tjänster och portar
• om användar- eller gruppmatchning är nödvändig
• om NAT är inblandat
• om loggning ska vara permanent aktiv
• vilka säkerhetsfunktioner som är lämpliga, till exempel IPS, Web Policy eller Application Control
• vem är tekniskt ansvarig för åtkomst

De faktiska brandväggsreglerna skapas sedan från denna matris. De detaljerade alternativen och typiska fel för regelordning, källa, destination, NAT och loggning beskrivs i Förstå och korrekt konfigurera Sophos Firewall-regler.

Planeringskontroll före ändringar

Innan zoner eller gränssnitt skapas, flyttas eller tas bort bör beroenden klargöras skriftligen. Många senare fel orsakas inte av själva IP-adressen, utan av glömda brandväggsregler, NAT-regler, DHCP-servrar, Device Access eller routingbeslut.

För varje ny zon eller gränssnitt bör åtminstone dessa frågor besvaras:

• Nätverkets förtroendenivå: Zonen, brandväggsreglerna och Device Access beror på detta.
• Användare och system på nätverket: Klienter, servrar, gäster, IoT, VoIP och hantering behöver andra regler.
• Standardgateway: Brandväggen är ofta gatewayen för VLAN, men ibland inte för migrering.
• DHCP-källa: Sophos Firewall, intern DHCP-server eller DHCP-relä måste planeras medvetet.
• DNS-server: DNS påverkar webbfiltrering, namnupplösning och felsökning.
• Lokala brandväggstjänster: Device Access för DNS, Ping, HTTPS, SSH eller portaler måste matcha.
• Regler och NAT-vägar: Utan lämplig brandvägg och NAT-regler är gränssnittet endast tekniskt tillgängligt.
• Testflöde: En testklient, ett testmål och en förväntad loggpost sparar mycket söktid.

En aktuell säkerhetskopia bör också finnas tillgänglig för produktiva ändringar. Om gränssnitt redan används är Object usage obligatoriskt innan namn, zonbindning, IP-adress eller gränssnittstyp ändras.

Skapa ny zon

Öppna Network > Zones och klicka på Lägg till.

1. Tilldela ett kort, unikt namn, till exempel Server, Guest, Management eller MPLS.
2. Välj LAN eller DMZ som typ.
3. Under Device Access, ange medvetet vilka lokala brandväggstjänster som kan vara tillgängliga från denna zon.
4. Spara.

Efter sparandet bör zonen kontrolleras direkt på två ställen: under Network > Zones för namn, typ och Device Access samt senare i en test-brandväggsregel som valbar Source zone eller Destination zone. Om zonen finns men inget gränssnitt ligger i den kommer ännu ingen produktionstrafik att gå där.

LAN eller DMZ som zontyp?

För dina egna zoner kan du vanligtvis välja mellan LAN och DMZ på Sophos Firewall. Båda typerna grupperar gränssnitt så att de senare kan användas rent i regler, Device Access och policyer. Skillnaden ligger främst i säkerhetsidén bakom zonen.

LAN används för interna, i grunden pålitliga nätverk. Dessa inkluderar till exempel klientnätverk, interna servernätverk, hanteringsnätverk, VoIP, skrivare eller interna VLAN. Detsamma gäller för en LAN-zon: Trafik mellan gränssnitt är inte automatiskt tillåten. Om två LAN-zoner eller två gränssnitt inom en LAN-zon ska prata med varandra krävs lämpliga brandväggsregler.DMZ används för nätverk med högre risk eller tydlig isolering. Typiska exempel är allmänt tillgängliga webbservrar, omvända proxyservrar, e-postgateways, hoppvärdar eller system som måste vara tillgängliga från flera säkerhetsområden. En DMZ bör planeras så att den endast tar emot nödvändiga interna anslutningar. Om en komprometterad server finns i DMZ bör detta inte automatiskt resultera i utbredd åtkomst till det interna LAN.

Som en enkel tumregel:

• LAN: interna nätverk som är allmänt betrodda och som kommunicerar huvudsakligen utgående eller internt.
• DMZ: exponerade eller särskilt isolerade nätverk där intern åtkomst bör vara strikt begränsad.

HA-gränssnitt hör också hemma i en DMZ-zon. För vanliga administratörs- eller klientnätverk är LAN vanligtvis den mer lämpliga typen.HTTPS kan vara användbart för ett internt administratörsnätverk. För normala klient- eller gästnätverk bör hanteringsåtkomst undvikas. Ping/ping6 är ofta till hjälp för felsökning, men bör aktiveras medvetet. DNS behövs bara om klienter i denna zon använder brandväggen som en DNS-server.

⚠️ Device Access är inte detsamma som en brandväggsregel. Tillgång till lokala brandväggstjänster, till exempel WebAdmin, SSH, User Portal, DNS eller Ping, styrs via Administration > Device access och lokala ACL-undantag.

Konfigurera gränssnitt

Gränssnitt finns under Network > Interfaces. Till exempel kan en fysisk port drivas som ett LAN, WAN eller DMZ. Virtuella gränssnitt som VLAN, Bridge, LAG, RED eller XFRM skapas också.

Dessa punkter är särskilt viktiga för ett fysiskt gränssnitt:

• Name: beskrivande namn för senare regler och loggar.
• Hardware: fysisk port, till exempel Port1, Port2 eller PortA.
• Network zone: Säkerhetszon där gränssnittet finns.
• IPv4 configuration: Statisk, DHCP eller PPPoE.
• IPv6 configuration: Statisk, DHCP eller delegerad, beroende på miljön.
• Gateway: endast relevant för WAN-gränssnitt.
• MTU / MSS: viktigt för PPPoE, VPN, SD-WAN och fragmenteringsproblem.

Endast gränssnitt i WAN-zonen får en gateway-konfiguration. Interna gränssnitt adresseras vanligtvis statiskt. DHCP eller PPPoE kan vara användbart för leverantörsanslutningar.

Om leverantören tillhandahåller IPv6 via prefixdelegering bör du planera begränsningarna och processen separat. Den praktiska artikeln för detta är Konfigurera IPv6-prefixdelegering till Sophos Firewall.

Meningsfulla namn är viktiga. PortD säger lite efter sex månader. Server VLAN, MPLS Provider, Guest WiFi eller Core Switch Trunk hjälper betydligt mer i drift.

Ett befintligt fysiskt gränssnitt redigeras så här:

1. Öppna Network > Interfaces.
2. Öppna menyn för önskad port och välj Edit interface.
3. Kontrollera Name, Network zone, IP-konfiguration, gateway och MTU/MSS.
4. För WAN-gränssnitt, kontrollera även gatewaynamn och gateway-IP.
5. Spara och kontrollera sedan link status, gateway status och Log Viewer.

Innan ett produktionsgränssnitt ändras bör Object usage öppnas. Gränssnittsändringar kan påverka zone binding, DNS, gateways, SD-WAN routes, gränssnittsbaserade hosts, VLAN-gränssnitt, Dynamic DNS, brandväggsregler och NAT. När ett virtuellt gränssnitt tas bort kan Sophos dessutom ta bort beroende konfigurationer som brandväggsregler, DHCP- eller routingreferenser. Det är just där obehagliga avbrott uppstår om man bara hade portnamnet i huvudet.

Före firmware-uppgraderingar bör man dessutom se till att gränssnittsnamn, hårdvarunamn och branchnamn inte slutar med ett långt block med siffror. Ett WebAdmin-visningsfel dokumenteras i SFOS release notes om sådana namn slutar med tio eller fler siffror, till exempel VLAN_1234567890. Kontrollera Sophos Firewall före SFOS 22-uppgradering är lämplig för uppgraderingsplanering och specifika tester.

Skapa VLAN-gränssnitt

För en fokuserad process med föräldragränssnitt, switchtaggning, DHCP, Device Access, brandväggsregler och tester är Sophos Firewall Konfigurera och testa VLAN lämplig. Följande avsnitt klassificerar VLAN inom den större gränssnitts- och zonmodellen.

Ett VLAN-gränssnitt skapas under Network > Interfaces > Add interface > Add VLAN. Föräldergränssnittet, zonen, VLAN-ID och IP-konfigurationen är särskilt viktiga.

Det överordnade gränssnittet är den fysiska porten eller en LAG som VLAN:et kommer taggat till. Om switchen skickar VLAN till en annan port, omärkt eller med ett felaktigt VLAN-ID, ser brandväggen ett VLAN-gränssnitt, men klienterna kan inte nå det tillförlitligt. För interna VLAN används vanligtvis en statisk IP-adress på brandväggen, till exempel som standardgateway för detta VLAN. Zonen bestämmer senare vilka brandväggsregler, webbpolicyer och Device Access-inställningar som gäller. Det är precis därför du inte bara ska ange IP-adressen när du skapar ett VLAN, utan också överväga direkt om VLAN kräver Client, Server, Management, Guest, DMZ eller en annan zon.

Ett konkret praktiskt exempel med switchportprofiler, taggat/otaggat beteende, DHCP och testsekvens finns i Konfigurera VLAN på Sophos Firewall och UniFi Switch.

På XGS-hårdvara anger Sophos inget fast hårt antal VLAN-gränssnitt per fysiskt gränssnitt. Det betyder inte att en enda parent port alltid är det bästa driftvalet. För prestanda, felsökning och underhållbarhet bör VLAN fördelas rimligt över fysiska portar eller LAGs, särskilt vid många VLAN, hög east-west-belastning eller HA-designer.

Rengör VLAN-utbyggnad

Ett VLAN anses bara vara komplett när inte bara gränssnittet har skapats, utan även switchen, DHCP, DNS, brandväggsregler och loggning passar ihop. Speciellt med nya nätverk är det lätt att söka på fel ställe: brandväggsregeln ser korrekt ut, men switchen skickar otaggade. Eller så får klienten en IP-adress, men Device Access tillåter inte DNS-åtkomst till brandväggen.

För varje nytt VLAN bör dessa punkter kontrolleras:

• Brandväggsgränssnitt: VLAN-ID, föräldragränssnitt, zon, IP-adress och nätmask matchar designen.
• Switch port: Upplänk till brandväggen är konfigurerad som en trunk och har VLAN-märkt.
• Åtkomstport eller SSID: Klientport eller WLAN SSID mappar klienter till rätt VLAN.
• Gateway: Brandväggens IP i VLAN är den förväntade standardgatewayen eller så är routingen dokumenterad annorlunda.
• DHCP: DHCP-server, DHCP-relä eller extern DHCP-server distribuerar korrekt IP, gateway, DNS och leasing.
• DNS: Klienter kan lösa interna och externa namn som planerat.
• Device Access: Endast obligatoriska lokala brandväggstjänster är tillåtna från zonen, till exempel DNS eller Ping.
• Brandväggsregel: Källzon, källnätverk, destinationszon, tjänster och loggning matchar testflödet.
• NAT: Endast aktiv om trafik verkligen behöver översättas. För normal intern trafik är NAT vanligtvis fel.
• Test: Log Viewer visar den förväntade brandväggen Rule ID; vid behov bekräftar Packet Capture paketflödet.

Som ett acceptanstest räcker det inte att en klient får någon IP-adress. Ett användbart test består av flera steg: anslut klienten via DHCP, pinga gatewayen, kontrollera DNS, testa en tillåten intern anslutning, se att förbjuden åtkomst är avsiktligt blockerad och kontrollera sedan internetåtkomst. På så sätt kan du se om VLAN, zon, Device Access, brandväggsregel och NAT verkligen matchar.

Om flera VLAN skapas samtidigt bör du använda en separat testklient eller minst en unik test-IP för varje VLAN. Annars kommer Log Viewer och Packet Capture att bli onödigt förvirrande. Testa brandväggsregeln med Log Viewer, Policy Test och Packet Capture är lämplig för själva paketflödeskontrollen.

Läs gränssnittets status korrekt

Under Network > Interfaces visar Sophos Firewall statusmeddelanden. Dessa statusmeddelanden är mycket användbara vid felsökning eftersom du snabbt kan se om ett gränssnitt bara är felaktigt konfigurerat eller om det verkligen inte finns någon länk.

• Not configured: Gränssnittet är inte tilldelat en zon. Så det kan inte användas på något meningsfullt sätt förrän en zon har bestämts.
• Connected: Gränssnittet är konfigurerat och anslutet.
• Connecting: En ny IP-adress erhålls för närvarande, till exempel via DHCP.
• Disconnected: IP-adressen har släppts.
• Disconnecting: IP-adressen släpps för närvarande.
• Unplugged: Det finns ingen fysisk anslutning. För WiFi kan det också innebära att ingen Access Point är ansluten eller att inget trådlöst nätverk är tilldelat.
• Not available: FleXi-portar har konfigurerats, men motsvarande FleXi-portmodul finns inte längre.

Om ett gränssnitt oväntat visar Not configured eller Unplugged bör du inte söka efter brandväggsregler först. Först kontrollerar du zonbindning, länk, SFP/transceiver, kabel, switchport och, för DHCP/PPPoE, adresstilldelningen.

Klassificera VLAN, Bridge, LAG, Alias och RED

Sophos Firewall stöder olika gränssnittstyper. För nybörjare är det viktigaste när vilken typ är vettig.

• VLAN: Standard för segmenterade nätverk på en trunkport.
• Bridge: Transparent anslutning av flera portar, ofta för enkla inställningar eller migrering.
• LAG: Samling av flera fysiska länkar för redundans eller bandbredd.
• Alias: ytterligare IP-adress på ett befintligt gränssnitt.
• RED: Remote Ethernet Device för externa platser.
• XFRM: Ruttbaserat IPsec VPN-gränssnitt.

Alias-gränssnitt underskattas ofta. De är särskilt användbara när en provider tillhandahåller flera publika IP-adresser i samma subnet. Flera separata WAN-gränssnitt i samma subnet orsakar ARP-problem på Sophos Firewall och kan göra gateways onåbara. I sådana designer är ett alias på det befintliga WAN-gränssnittet eller en välplanerad LAG oftast det bättre valet.

För nya installationer är VLAN på en tydligt definierad upplänk till switchen vanligtvis renare än en stor brygga över många portar. En brygga kan vara användbar för migrering eller mycket enkla inställningar eftersom flera portar behandlas som ett gemensamt lager 2-segment. Men det är just det som är nackdelen: säkerhetsgränser, sändningsdomäner och felkällor blir mindre tydligt synliga.

Vi rekommenderar därför endast broar specifikt och inte som standardutförande. I praktiken har broar flera nackdelar:

• Flera portar delar samma Layer 2-segment, vilket gör att sändningar och störningar lättare påverkar flera enheter. – Brandväggsreglerna blir allt mindre tydliga eftersom separationen inte längre är tydligt synlig över dina egna gränssnitt, VLAN och zoner. – Felsökning blir svårare eftersom paketflöde, MAC-inlärning, STP-problem och switchkonfiguration måste övervägas tillsammans. – Senare segmentering blir mer komplex om separata klient-, server-, gäst- eller förvaltningsnätverk ska skapas från en enkel brygga.
• HA-, VLAN-, DHCP- eller enhetsåtkomstdesigner blir snabbt förvirrande om för många funktioner körs över en brygga.

Broar kan skapas på Sophos Firewall via fysiska gränssnitt, RED-gränssnitt, VLAN eller LAG och drivas med eller utan sin egen IP-adress. Det är precis där missförstånd ofta uppstår:

• Utan en IP-adress fungerar bryggan transparent, men kan inte användas som ett vanligt rutat gränssnitt.
• Om routing krävs på en brygga måste bryggan tilldelas en IP-adress.
• För trafik mellan bryggmedlemmar krävs fortfarande lämpliga brandväggsregler mellan de inblandade zonerna, till exempel LAN till LAN. – STP kan vara användbart om det finns redundanta vägar och broslingor ska förhindras. När HA är aktivt kan STP dock inte aktiveras på Bridge-interfaces.
• VLAN-filter och EtherType-filter kan hjälpa till att begränsa Layer 2-trafik som passerar genom en bro. Om ett VLAN-filter är aktivt men inga tillåtna VLAN har angetts släpper firewallen taggad traffic för alla VLAN. Otaggad traffic påverkas inte.
• Trafik över brygggränssnitt utan IP-adress kan släppas om den träffar en brandväggsregel med webbproxyfiltrering eller en NAT-regel. Sådana droppar loggas inte. Med NAT måste du vara särskilt uppmärksam på källöversättningen eller åsidosätta källöversättningen.

Den sista punkten är viktig: Om du plötsligt inte ser några loggar över en bro, även om trafiken inte verkar fungera, är problemet inte alltid med Log Viewer. Det kan bero på bryggläget, NAT eller webbproxyfiltrering.

Om VLAN redan finns på switchen bör brandväggen medvetet anta dessa VLAN som sina egna VLAN-gränssnitt. Detta resulterar i tydligare zoner, renare brandväggsregler och är vanligtvis lättare att underhålla på lång sikt.

SFOS 22: Kontrollera bro, SNAT och hårnålstrafik

Med SFOS 22 finns det ytterligare ett specialfall för bro som snabbt förbises vid migrering. Routing över ett brygggränssnitt kan misslyckas om SNAT eller MASQUERADE tillämpas på trafik över bryggan och källan och destinationen kan nås via samma fysiska bryggmedlem. I detta hårnålsscenario kan svarspaket släppas på bryggan utan att droppen syns rent i drppkt.

Detta är inte ett normalt regelmatchningsproblem. Om Log Viewer visar lite, regeln ser korrekt ut och fortfarande bara vissa anslutningar över en brygga misslyckas, bör du kontrollera NAT och bryggtopologi tillsammans:

• Behövs verkligen SNAT eller MASQUERADE på brotrafiken?
• Kommer källa och destination via samma fysiska bromedlem?
• Finns det bara en aktivt använd bromedlem?
• Skulle en dirigerad design eller ett dedikerat fysiskt gränssnitt vara renare?
• Kan trafik testas utan källöversättning?

Det finns även ett separat SFOS 22-fodral för VLAN-märkt trafik till själva brandväggen. Den praktiska proceduren finns i Sophos Firewall Kontrollera brygg-VLAN enligt SFOS 22.

RED Bridge: Sträck ut nätverk över platser

Det är tekniskt möjligt att inkludera RED-gränssnitt i en brygga och på så sätt sträcka ett Layer 2-nätverk över flera platser. Detta kan hjälpa i speciella fall, till exempel när en applikation måste finnas kvar i samma subnät eller en migrering ska ske utan omedelbara IP-ändringar.

Vi rekommenderar endast denna design mycket försiktigt. En bro över RED förlänger Layer 2-domänen över tunneln. Detta gör att sändningar, ARP, okända unicast-paket och andra Layer 2-effekter körs över en WAN- eller Internetanslutning. Detta kan försämra prestandan och göra fel svårare att förstå. Om den RED tunneln är instabil kommer detta också att direkt påverka det utsträckta nätet.

I de flesta fall är en routad design bättre: Varje plats har sina egna undernät, brandväggsvägarna mellan nätverken och brandväggsreglerna definierar specifikt vad som är tillåtet. Detta är renare, mer skalbart och mycket bekvämare vid felsökning.

LAG: Planera redundans och bandbredd korrekt

En Link Aggregation Group (LAG) kombinerar flera fysiska portar till ett logiskt gränssnitt. Detta är vettigt om du behöver redundans till kärnswitchen eller vill ge mer bandbredd mellan brandväggen och switchen. Men LAG ersätter inte ren zonindelning. I slutändan är LAG-gränssnittet fortfarande bara ett gränssnitt på vilket du till exempel kan driva VLAN eller tilldela en zon.

Sophos Firewall stöder huvudsakligen två typiska driftlägen:

• Active-Backup: En länk är aktiv, en annan tar över om den misslyckas. Detta är enkelt och bra för redundans.
• LACP (802.3ad): Flera länkar kan användas parallellt. Detta kräver LACP på båda sidor, dvs på brandväggen och switchen.

Det är viktigt: LACP fungerar bara korrekt om den andra sidan är korrekt konfigurerad. På switchen måste portarna vara i samma LAG-grupp, använda samma hastighet och duplexläge och matcha brandväggskonfigurationen. Om du bara skapar en LAG på brandväggen men inte konfigurerar switchen på rätt sätt, uppstår ofta paketförluster som är svåra att förstå eller asymmetriska anslutningsproblem.

Några praktiska begränsningar gäller för LAG:er:

• En LAG på Sophos Firewall består av två till fyra fysiska gränssnitt.
• Endast obundna fysiska gränssnitt med statisk konfiguration är lämpliga som medlemmar.
• PPPoE, Cellular WAN och WLAN-gränssnitt kan inte användas som LAG-medlemmar.
• För LACP (802.3ad) måste medlemsportarna ha samma typ och hastighet.
• xmit-hash-policy bestämmer hur sessioner fördelas över länkarna. En enskild TCP-session blir normalt inte plötsligt snabbare eftersom den vanligtvis stannar på en länk.

För små miljöer räcker det ofta med en enda ren trunkport. LAG är särskilt värdefullt om kärnswitchen ska anslutas redundant, om många VLAN kör över samma upplänk eller om brandväggen verkligen behöver mer genomströmning till switchen.

XFRM: Förstå ruttbaserad IPsec som ett gränssnittEtt XFRM-gränssnitt tillhör ämnet ruttbaserad IPsec VPN. Den är inte planerad som ett vanligt VLAN eller fysisk port, utan skapas i samband med en IPsec-anslutning. Sophos Firewall skapar ett XFRM-gränssnitt automatiskt när både de lokala och fjärranslutna subnäten är inställda på Any på en IPsec-anslutning.

Detta är en viktig skillnad mot klassiska policybaserade IPsec-tunnlar. Med ruttbaserad VPN avgör inte bara IPsec-policyn utan även routing, brandväggsregler och XFRM-gränssnittet vart trafiken går. Detta gör mer komplexa platsanslutningar mer flexibla, men kräver noggrann planering:

• XFRM-gränssnittet är i VPN-zonen.
• Under Administration > Device access måste IPsec tillåtas för WAN-zonen så att anslutningen kan upprättas.
• Om lokala eller fjärranslutna undernät inte är Any skapas inget XFRM-gränssnitt.
• MTU och MSS är särskilt viktiga för ruttbaserad VPN eftersom IPsec skapar ytterligare overhead. Den praktiska testproceduren finns i Sophos Firewall Kontrollera MTU och MSS för VPN-problem.
• Ett XFRM-gränssnitt avaktiveras inte direkt under Network > Interfaces, utan snarare via den tillhörande IPsec-anslutningen under Site-to-site VPN > IPsec.

XFRM är särskilt relevant för administratörer när SD-WAN-routing, dynamisk routing eller flera nätverk måste kontrolleras ordentligt via en platstunnel. Om allt du behöver är en mycket enkel plats-till-plats-anslutning med två fasta nätverk, är en klassisk policybaserad tunnel ofta lättare att förstå.

RED: Externa platser som ett separat gränssnittskonceptRED-gränssnitt är inte en normal switchport. RED står för Remote Ethernet Device och används för att ansluta en extern plats till Sophos Firewall via en krypterad tunnel. Detta kan implementeras med dedikerad SD-RED-hårdvara eller med brandvägg-till-brandvägg RED-anslutningar.

Innan du planerar bör det vara klart vilket driftläge som krävs:

• Standard/Unified: Brandväggen hanterar fjärrnätverket. Trafiken går genom den centrala brandväggen. Mycket lätt att styra, men beroende av tunneln.
• Standard/Split: Endast definierade målnätverk går genom tunneln, Internettrafik slocknar lokalt på platsen. Mindre bandbredd över huvudkontoret, men mindre central kontroll.
• Transparent/Split: RED hänger transparent i ett befintligt nätverk. Bra för speciella fall, men svårare att förstå och inte lämplig för varje design.
• Manual/Split: Mer manuell nätverkskonfiguration. Platsen kan fortsätta att fungera lokalt om tunneln misslyckas.

För många företag är Standard/Unified det renaste alternativet om platsen behöver skyddas helt via den centrala brandväggen. Nackdelen är tydlig: Om den RED tunneln misslyckas förlorar platsen också centralt styrd internetåtkomst, beroende på designen. Standard/Split minskar detta beroende, men innebär också att lokal internettrafik inte längre helt filtreras och loggas via den centrala Sophos Firewall.

Med RED bör du kontrollera dessa punkter tidigt:

-RED-tjänsten måste aktiveras på System services > RED.

• TCP 3400, UDP 3410 och NTP 123 krävs vanligtvis för anslutningen.
• SD-RED-enheter behöver korrekt tid, annars kan TLS-handskakning och tunneletablering misslyckas.
• Vid idrifttagning för första gången är DHCP på upplänken vanligtvis lättare eftersom enheten måste uppnå provisionering.
• VLAN är inte lika användbara i alla RED lägen. Standard/Split och Transparent/Split är inte avsedda för VLAN-taggade ramar. Om VLAN krävs bakom en SD-RED, bör du välja driftläge särskilt noggrant.
• Om en RED-enhet ligger bakom en leverantörsrouter måste utgående anslutningar och DNS/NTP fungera.

RED är mycket praktiskt för små platser, men du bör inte behandla det som en vanlig LAN-kabel. Det avgörande är om platsen ska vara centralt skyddad, lokalt autonom eller endast delvis sammankopplad via tunneln. Detta beslut påverkar DHCP, DNS, VLAN, routing, brandväggsregler, loggning och felsökning.

Device Access rent begränsaUnder Administration > Device access kan du se vilka lokala brandväggstjänster som är tillgängliga från vilka zoner. Dessa inkluderar bland annat:

• HTTPS
• SSH
• User Portal
• VPN Portal
• DNS
• Ping/Ping6
• Captive Portal
• STAS
• Wireless Protection

För produktiva miljöer gäller att ju färre lokala tjänster som kan nås från en zon, desto bättre. I synnerhet bör HTTPS och SSH endast tillåtas från pålitliga hanteringsnätverk eller via en Local service ACL-undantagsregel.

Om SSH behövs hjälper den här guiden: Upprätta en SSH-anslutning till Sophos Firewall.

För egna zoner kan Device Access också vara synligt direkt när zonen skapas eller redigeras. Tekniskt handlar det fortfarande om lokala firewall-tjänster, inte om normal transittrafik. Om klienter använder firewall som DNS-server måste DNS vara tillåtet för den zonen. Om administratörer behöver nå WebAdmin bör det inte öppnas brett för hela klientzonen, utan via ett managementnät eller ett Local Service ACL-undantag.

Tänk på beroenden

Ändringar av gränssnitt är sällan isolerade. Zone binding, DNS, gateways, SD-WAN routes, gränssnittsbaserade hosts, VLAN-gränssnitt, Dynamic DNS, brandväggsregler och NAT-regler kan bero på samma gränssnitt. Före större ändringar bör man kontrollera under Object usage var ett gränssnitt, en zon eller ett värdobjekt redan används. Sophos Firewall visar objektanvändningen och länkar direkt till många beroende konfigurationer.

Du måste vara särskilt försiktig när du avaktiverar eller tar bort:

• Om ett gränssnitt är avaktiverat behålls konfigurationen och statusen är fortfarande synlig.
• Plats-till-plats IPsec-tunnlar där brandväggen är initiator kopplas omedelbart bort.
• Plats-till-plats IPsec-tunnlar som svarsmottagare och fjärråtkomstanslutningar kopplas senast från på grund av inaktivitet eller detektering av döda peer.
• Alias ​​​​och XFRM-gränssnitt kan inte avaktiveras direkt som vanliga gränssnitt. Aliasgränssnitt följer det fysiska gränssnittet, XFRM-gränssnitt avaktiveras via Site-to-site VPN > IPsec.
• När ett virtuellt gränssnitt tas bort kan beroende brandväggsregler, DHCP-konfigurationer, ARP-poster, rutter, gränssnittsvärdar och andra referenser tas bort med det.

Innan du tar bort bör du därför alltid kontrollera om gränssnittet används i brandväggsregler, NAT-regler, DHCP, routing, SD-WAN, dynamisk DNS eller värdobjekt. En slarvig radering kan ta bort mer än bara själva gränssnittet.

Implementera ändringar säkert

Gränssnittsförändringar bör ske gradvis. Fjärrplatser, HA-kluster, WAN-gränssnitt, VLAN-trunkar, XFRM-gränssnitt och hanteringsnätverk är särskilt kritiska. En liten ändring av zonbindningen kan räcka för att brandväggsregler, Device Access eller SD-WAN-rutter inte längre ska fungera som förväntat.

Beprövad process:

1. Dokumentera aktuellt gränssnitt och zonkonfiguration.
2. Kontrollera beroenden via Object usage och notera de viktigaste träffarna direkt.
3. Skapa säkerhetskopia.
4. Definiera underhållsfönster eller reservtid.
5. Lägg till en ny zon eller ett nytt gränssnitt först, ta inte bort den gamla konfigurationen omedelbart.
6. Förbered testklient eller testtrafik.
7. Efter ändring, kontrollera länkstatus, IP-adress, gateway, DHCP och DNS.
8. Validera brandväggsregel, NAT-regel och Device Access med Log Viewer eller Packet Capture.
9. Ta bara bort gamla regler, gränssnitt eller objekt när den nya sökvägen är stabil.

En säkerhetskopia är bara en del av vägen tillbaka. Innan kritiska gränssnitt eller zonändringar bör det även dokumenteras vilken gammal IP-adress, zon, VLAN-ID, gateway, rutt, SD-WAN-rutt, brandväggsregel och NAT-regel som måste återställas vid eventuell avbrytning. Sophos Firewall Skapa eller återställ säkerhetskopia är lämplig för själva säkerhetskopieringen och återställningsprocessen.

• Management zone eller Device Access justeras: Alternativ admin-åtkomst testas innan den gamla tillgängligheten tas bort.
• WAN-gränssnitt eller gateway har ändrats: Gammal leverantörssökväg, PPPoE/DHCP/statiska värden och SD-WAN-rutt dokumenteras.
• VLAN-trunken konverteras: Gammalt VLAN-ID, inbyggt VLAN, switchportprofil och brandväggsgränssnitt är spårbara.
• Bron, LAG eller RED ändras: Länkstatus, inblandade portar och platsåtkomst kan kontrolleras oberoende.
• XFRM- eller VPN-gränssnitt har ändrats: Tunnel-, routing- och brandväggsregler valideras innan den gamla sökvägen tas bort.

Särskild uppmärksamhet bör ägnas åt taggat/otaggat beteende under VLAN-migreringar. Om switchen och brandväggen använder olika VLAN-ID, inbyggda VLAN eller trunkprofiler, ser brandväggen antingen ingen trafik alls eller så hamnar trafiken i fel zon.

För avlägsna platser bör det alltid finnas en åtkomstväg utanför det gränssnitt du just ändrade. Detta kan vara Sophos Central, en andra WAN-åtkomst, en lokal administratör på plats eller ett separat hanteringsnätverk.

Typiska stötestenar

Gränssnittet är obundet eller inaktiverat: Kontrollera först om en zon är tilldelad. Ett fysiskt gränssnitt kan inte tas bort, men dess konfiguration kan tas bort genom att ställa in zonen till None.

VLAN fungerar inte: Kontrollera VLAN ID, Switch Port, Tagged/Otagged Configuration, Native VLAN och Parent Interface.

Kunder kan inte nå brandväggen via ping eller HTTPS: Kontrollera inte normala brandväggsregler först. Administration > Device access och lokala ACL-undantag är avgörande.

Trafik mellan två interna nätverk fungerar inte: Kontrollera källzon, destinationszon, nätverksobjekt, routing och position för brandväggsregeln.

WAN-gateway blir inte aktiv: Kontrollera IP-konfiguration, gateway-IP, länkstatus, PPPoE-referenser, DNS och vid behov WAN-länkhanterare.

Flera WAN-gränssnitt i samma undernät: Om flera WAN-gränssnitt använder IP-adresser från samma undernät kan ARP-problem uppstå och gateways kan bli oåtkomliga. Om en leverantör tillhandahåller flera offentliga IP-adresser på samma undernät, är alias- eller LAG-gränssnitt vanligtvis renare än flera separata WAN-gränssnitt på samma nätverk.

SFP, porthastighet eller breakout stämmer inte överens: Porthastigheten på switchen, routern, transceivern och brandväggen måste matcha. En 25 Gbit/s-port kan inte anslutas direkt till en 40 Gbit/s-port utan lämplig teknik. För modeller med 40G- eller 100G-portar kan breakout-kablar vara aktuella om en port ska delas upp i flera mindre portar.

MTU-problem med VPN eller PPPoE: Kontrollera MTU och MSS. För VPN-trafik kan ett för högt MTU-värde leda till paketförlust, vilket i vardagen ser ut som slumpmässiga anslutningsproblem. Sophos Firewall Kontrollera MTU och MSS för VPN-problem är lämplig för systematisk begränsning.

Felsökning

Denna beställning är praktisk för felsökning:

1. Network > Interfaces: Kontrollera länkstatus, IP-adress, zon och gateway.
2. Network > Zones: Kontrollera Device Access och zontyp.
3. Värdar och tjänster: Kontrollera om värd- och tjänstobjekt är korrekta.
4. Rules and policies > Firewall rules: Kontrollera källzon, destinationszon, tjänster och beställning.
5. Rules and policies > NAT rules: Om NAT är inblandat, jämför originalet och den översatta noggrant.
6. Loggvisare: Kontrollera vilken regel eller släpp som gäller.
7. Diagnostics > Tools > Packet capture: Kontrollera om paket alls anländer och vart de vidarebefordras.

Om zoner och gränssnitt är korrekt upplagda blir nästa steg mycket enklare: Förstå och korrekt konfigurera Sophos Firewall-regler. Om trafiken inte fungerar trots den till synes korrekta zonen, hjälper checklistan Brandväggsregeln fungerar inte: kontrollera ordning, matchning och loggar. För en djupare analys kan du också använda Använd Packet Capture i WebAdmin och för översättningar eller portforwarding artikeln Förstå NAT på Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Operationell checklista

• Zonmodell dokumenterad: Klient, server, hantering, gäst, DMZ, WAN och VPN avsiktligt separerade eller avsiktligt kombinerade.
• Nya VLAN dokumenterade med VLAN ID, föräldragränssnitt, switchportprofil och gateway IP.
• Zon och konkret IP-hostobjekt dokumenterade för varje viktigt nätverk.
• Device Access kontrolleras per zon, speciellt för HTTPS, SSH, DNS, Ping, User Portal och VPN Portal.
• Brandväggsregler skapade med källzon, destinationszon, tjänster och loggning.
• Alias kontrollerat i stället för ett extra WAN-gränssnitt när flera publika IP-adresser används i samma provider-subnet.
• NAT-regler kontrollerade om internetåtkomst, DNAT, SNAT eller VPN är inblandade.
• DHCP, DNS och NTP testade för nya nätverk.
• Object usage kontrolleras innan ändringar av befintliga gränssnitt.
• Länkstatus, Log Viewer och Packet Capture kontrollerade för ändringar.
• Ledningsåtkomst säkerställs via en oberoende väg.
• Säkerhetskopiering tillgänglig före större förändringar.

Vanliga frågor