Konfigurera och testa ett brygggränssnitt på Sophos Firewall

Ett brygggränssnitt kopplar samman två eller flera gränssnitt på lager 2. På så sätt kan en Sophos Firewall placeras i en befintlig nätverksväg utan att klienternas subnät eller Default Gateway behöver ändras. Bryggan kan fungera transparent utan IP-adress eller routa med en egen IP-adress.

I exemplet i den här artikeln placeras brandväggen mellan en befintlig router och kärnswitchen. Port4 är vänt mot routern och tillhör zonen WAN, medan Port3 är vänt mot den interna switchen och tillhör zonen LAN. Själva bryggan får ingen IP-adress. WebAdmin förblir åtkomligt via en separat hanteringsport.

⚠️ När konfigurationen sparas tar bryggan över sina medlemsgränssnitt. Fel zon, en saknad hanteringsväg eller en redundant lager 2-väg kan bryta åtkomsten eller orsaka en loop. Skapa en säkerhetskopia i förväg, dokumentera kabeldragningen och testa en oberoende administratörsåtkomst. Anslut inte en andra fysisk väg förrän STP och en eventuell HA-design har klarlagts.

Vilket bryggläge passar ändamålet?

Transparent brygga utan IP-adress

En transparent brygga vidarebefordrar Ethernet-ramar mellan sina medlemmar, men fungerar inte som gateway. Slutenheternas IP-adresser, subnät och Default Gateway förblir oförändrade. Det passar vid en kontrollerad migrering eller som ett extra säkerhetslager mellan en befintlig router och det interna nätet. Beroende på regel och licens kan SFOS tillämpa DPI, IPS, skanning efter skadlig kod och e-postkontroll där, trots att den befintliga routern fortfarande är gateway.

Transparent betyder inte ofiltrerad. Medlemmarnas zoner avgör vilken brandväggsregel som kan tillämpas. För exempelflödet från Port3 i zonen LAN till Port4 i zonen WAN krävs en lämplig LAN-to-WAN-regel. Om båda medlemmarna ligger i LAN krävs i stället en LAN-to-LAN-regel.

I Planera zoner och gränssnitt på Sophos Firewall beskrivs hur du väljer förtroendenivåer, skapar egna zoner och tilldelar gränssnitt. De bryggspecifika besluten behandlas i sin helhet i den här artikeln. Grundartikeln är till hjälp när zonmodellen är ny eller inkonsekvent.

Om bryggan saknar IP-adress bör administrationen ske via ett annat gränssnitt. I exemplet använder Port2 ett separat hanteringsnät. Då förblir WebAdmin åtkomligt även om bryggan, dess regler eller kabeldragningen ännu inte är korrekt konfigurerade.

Routad brygga med IP-adress

Med Enable routing on this bridge pair får bryggan en IP-adress och kan fungera som gateway eller lokal slutpunkt på brandväggen. Det förändrar funktionen i grunden: utöver vidarebefordran på lager 2 tillkommer routad trafik, lokala tjänster och eventuella beroenden av gatewayen.

VLAN-filtreringen på bryggan gäller fortfarande endast ramar som bryggas. Den filtrerar inte trafik som bryggan routar. Om bryggan används som gateway måste därför även routing, Device Access, brandväggsregler och NAT kontrolleras.

SFOS 22-hjälpen ger motstridiga besked om DHCP. För IP-tilldelningen till en routad brygga anges Static och DHCP, men i samma dokument anges DHCP clients som en bryggfunktion som inte stöds. Använd därför en statisk adress för en förutsägbar produktionsdesign. DHCP på en brygga bör endast användas efter kontroll av den aktuella SFOS-versionen och bekräftelse från Sophos.

Bridge Mode i installationsguiden

Bridge Mode i den inledande installationsguiden och ett brygggränssnitt som senare skapas under Network > Interfaces bygger på samma lager 2-princip, men arbetsflödena är inte desamma.

På en ny enhet har Port A som standard adressen 172.16.16.16/24, medan Port B hämtar sin adress via DHCP. Vid den första installationen kan en dator exempelvis konfigureras med 172.16.16.2/24 och anslutas till Port A. WebAdmin är då åtkomligt på https://172.16.16.16:4444. Välj Internet gateway (Bridge Mode) i guiden. Efter registrering och inställning av skydd och aviseringar tillämpar SFOS konfigurationen och startar om.

Det här läget är avsett för en fullständig förstagångsinstallation. Kör inte guiden på nytt på en befintlig brandvägg bara för att lägga till ett nytt bryggpar. Om guiden körs efter att en HA-konfiguration redan har upprättats stängs HA av.

Bridge Mode stöder HA. Samtidigt går det inte att aktivera SFOS STP-funktion på något brygggränssnitt så länge HA är aktiverat. Detta ska skiljas från vidarebefordran av STP-, RSTP- och Multicast Routing-paket. En transparent brygga kan släppa igenom sådana ramar utan att själv delta i loopskyddet via SFOS-alternativet Turn on Spanning Tree Protocol (STP).

Planera exemplet före konfigurationen

Topologi och exempelvärden

Den befintliga routern förblir Default Gateway för nätet 10.20.0.0/24. Brandväggen placeras transparent i dess LAN-väg:

Internet
   |
Befintlig router: 10.20.0.1
   |
Port4, zon WAN
[ Bridge_Inline / brinline / ingen IP-adress ]
Port3, zon LAN
   |
Kärnswitch och klienter: 10.20.0.0/24

Separat hanteringsväg:
Port2, zon LAN, 10.99.0.1/24

Efter installationen använder en klient med 10.20.0.50/24 fortfarande 10.20.0.1 som gateway. Bryggan får varken en adress från 10.20.0.0/24 eller någon Default Route. Portnummer, zoner, hanteringsnät och regler måste anpassas. Kopiera inte exempelnätet rakt av till en produktionsmiljö.

Dokumentera två tillstånd före ombyggnaden: vilka anslutningar som fungerar före installationen och via vilken väg brandväggen kan administreras om produktionsdatavägen slutar fungera. Dokumentationen ska åtminstone omfatta DNS, gateway, en typisk applikation, förväntad genomströmning och åtkomst till WebAdmin.

Kontrollera medlemmar, zoner och beroenden

En brygga kan innehålla upp till 64 medlemmar. Följande kan användas som medlemmar:

• fysiska gränssnitt;
• RED-gränssnitt;
• LAG:er;
• VLAN-gränssnitt på ett fysiskt gränssnitt, RED eller en LAG.

Fler medlemmar är inget kvalitetsmått. Varje ytterligare anslutning utökar lager 2-domänen och MAC-tabellen samt ökar antalet möjliga loopar. För en inline-väg räcker normalt två medlemmar.

Kontrollera varje gränssnitt med avseende på befintliga IP-adresser, VLAN, DHCP, gateways, NAT, brandväggsregler, routing, Device Access och Object Usage innan det läggs till. En ports tidigare funktion försvinner inte automatiskt från alla beroende objekt bara för att porten blir en del av en brygga.

Enligt Sophos stöder brygggränssnitt inte Dynamic DNS, PPPoE eller IPsec VPN. Även uppgifterna om DHCP är motstridiga, enligt beskrivningen ovan. En brygga är därför ingen generell ersättning för ett WAN- eller VPN-gränssnitt. För nya, tydligt segmenterade nät är VLAN och routing ofta enklare att hantera.

LAN Bypass är en separat maskinvarufunktion, inte den normala funktionen hos en godtycklig brygga. I Konfigurera och testa LAN Bypass under kontrollerade former beskrivs vilka modeller och portpar som stöder funktionen och vad som händer vid ett fel.

Skapa bryggan i WebAdmin

Name, Hardware name och medlemmar

1. Öppna Network > Interfaces > Add interface > Add bridge.
2. Ange exempelvis Bridge_Inline som Name. Visningsnamnet får innehålla högst 58 tecken och kan ändras senare.
3. Ange exempelvis brinline som Hardware name. Värdet får innehålla högst 10 tecken och får endast bestå av bokstäver, siffror och _. Det kan inte ändras efter att konfigurationen har sparats.
4. Låt Enable routing on this bridge pair vara avaktiverat i det transparenta exemplet.
5. Lägg till Port3 med zonen LAN och Port4 med zonen WAN som Member interfaces.
6. Kontrollera inställningarna för VLAN, ARP, STP, MAC, MTU, MSS och EtherType.
7. Välj inte Save förrän den separata hanteringsåtkomsten fungerar och båda kablarna är tydligt märkta.

SFOS blockerar reserverade maskinvarunamn. Den fullständiga listan i SFOS 22-hjälpen är:

all, gre, oct, mv-pcimux0, mvmgmt0, pport_, lo, ipsec0, tun, ppp,
imq, ifb, mast, sit, WWAN1, _ppp, vxlan, xfrm, USB, erspan0, Port,
MGMT, eth, GE, gretap0, ip6tnl0, host, reds, wlnet, WLAN, Sophos,
GuestAP, spq, Halink

För en routad brygga anges dessutom IPv4 eller IPv6. Om bryggan innehåller WAN-medlemmar visas även gatewayfält. Dessa värden måste stämma överens med den faktiska routingdesignen. För den transparenta bryggan i exemplet lämnas fälten tomma.

VLAN- och EtherType-filter

Filter VLANs begränsar taggad trafik till de ID:n som anges under Permitted VLAN ID or ID range. Det går att ange både enskilda värden och intervall, till exempel 20-35. Om filtret är aktivt men listan är tom kasserar SFOS all taggad VLAN-trafik. Otaggad trafik fortsätter att passera. Just den kombinationen kan vara vilseledande vid felsökning.

VLAN-filtret gäller endast ramar som bryggan vidarebefordrar. Det ersätter varken brandväggsregler eller kontroll av routad trafik. Äldre VLAN-taggar från CLI kräver en separat kontroll i SFOS 22. Proceduren i Kontrollera brygg-VLAN efter SFOS 22 behandlar det specialfallet och anger vilka versioner som berörs.

Med Filter Ethernet frames går det att begränsa vilka EtherTypes som tillåts. Utan filter tillåter bryggan alla Ethernet-ramar. Om filtret är aktivt men inte innehåller några godkända typer tillåts endast ARP, IPv4, IPv6, 8021Q och EXTE. Andra protokoll anges med ett fyrsiffrigt hexadecimalt ID, exempelvis 809B för AppleTalk, 8138 för Novell samt 8863 och 8864 för PPPoE.

Tillåt inte en EtherType för säkerhets skull. Kontrollera först i Packet Capture vilket protokoll som faktiskt saknas. Annars skapas en svåröverskådlig undantagslista som ingen senare med säkerhet kan förklara.

ARP, STP och MAC Aging

Permit ARP broadcast är aktiverat som standard. Bryggan behöver ARP för att lära sig kopplingarna mellan IP- och MAC-adresser och bygga upp sin vidarebefordringstabell. Att stänga av alternativet ger inget generellt skydd mot broadcast-trafik. Det är endast lämpligt vid en verifierad ARP-storm och kräver statiska bindningar under Network > Neighbors (ARP–NDP).

Turn on Spanning Tree Protocol (STP) skyddar mot loopar om det finns mer än en lager 2-väg mellan samma områden. STP kan blockera en redundant väg och växla över om den aktiva vägen slutar fungera. Alternativet är inte tillgängligt på brygggränssnitt så länge HA är aktivt. Ett HA-kluster med redundant kabeldragning kräver därför en design där switchar, portvägar och loopskydd planeras som en helhet.

STP max age är som standard 20 sekunder. SFOS använder BPDU:er för att utbyta topologiinformation mellan bryggor. Värdet ska inte optimeras isolerat på brandväggen, utan måste passa hela STP-domänen.

MAC aging tar som standard bort inaktiva MAC-adresser efter 300 sekunder. Ett lägre värde kan reagera snabbare på enhetsbyten i ett mycket dynamiskt gäst- eller testnät. I ett stabilt datacenternät minskar ett högre värde onödig ominlärning. Ändra endast värdet om MAC-flapping, frekventa platsbyten eller ett konkret driftkrav motiverar det.

MTU och MSS

Om bryggan och dess medlemmar har olika MTU använder bryggan det lägre värdet. En brygga med MTU 9000 begränsas i praktiken till 1500 om en medlem endast stöder 1500. Det ärvda värdet visas i gränssnittstabellen.

Override MSS gäller TCP. Värdet begränsar nyttolasten per TCP-segment så att extra protokollhuvuden eller tunnelinkapsling inte överskrider den effektiva MTU:n. Det kan avhjälpa ett verifierat MTU- eller fragmenteringsproblem, men rättar inte till fel VLAN, en saknad regel eller en bruten returväg. MSS-begränsning gör inte UDP-trafik mindre. En utförlig diagnostikprocedur finns i Kontrollera MTU och MSS vid VPN-problem.

Brandväggsregler, NAT och Web Proxy

Bryggan kringgår inte den tillståndsbaserade brandväggen. I exemplet behöver klienttrafiken en regel från LAN till WAN. Använd 10.20.0.0/24 eller ett snävare objekt som Source Network, och begränsa Destination och Service till det som faktiskt behövs. Loggningen ska vara aktiverad under verifieringen.

Om du fortfarande behöver fastställa regelordning, zonmatchning eller skyddsfunktioner finns hela grundproceduren i Konfigurera brandväggsregler på Sophos Firewall. För bryggan är det avgörande via vilka medlemszoner den aktuella ramen kommer in och går ut.

Svarspaket i en tillåten anslutning som upprättats inifrån går tillbaka via det befintliga tillståndet. Det krävs ingen bred WAN-to-LAN-regel för detta. Nya inkommande anslutningar kräver däremot en egen, medvetet begränsad regel.

En brygga utan IP-adress medför en ovanlig typ av fel. Om trafiken matchar en brandväggsregel med Web Proxy Filtering eller en NAT-regel kan SFOS kassera paketen utan att skapa någon post i Log Viewer. En tom logg visar i detta fall inte att ingen regel är inblandad.

Om NAT-regeln behövs aktiverar du Override source translation for specific outbound interfaces i just den regeln. Ange bryggan som Outbound interface och Original som Translated source (SNAT). Då bevaras källadressen för denna utgång. En global NAT-ändring är ett dåligt test eftersom den påverkar andra datavägar och döljer det egentliga felet.

Använd endast Web Proxy Filtering på en transparent brygga utan IP-adress om designen och den aktuella SFOS-versionen uttryckligen medger det. För vanlig inline-inspektion är DPI-baserade regler en mer lättbegriplig utgångspunkt.

Verifiera datavägen och avgränsa fel

Verifiering efter att konfigurationen sparats

När konfigurationen har sparats testas konfigurationen, nyttotrafiken och felsituationen var för sig:

1. Jämför bryggnamn, Hardware name, medlemmar, zoner, IP-läge, ärvd MTU och länkstatus med planen under Network > Interfaces.
2. Anslut till en nödvändig tjänst från testklienten och bekräfta förväntat Firewall Rule ID i Log Viewer.
3. Jämför ingående och utgående trafik i Packet Capture. Source och Destination MAC, VLAN tag, EtherType och interface måste stämma överens med topologin.
4. Testa en tillåten tjänst i båda riktningarna. Starta sedan en tjänst som avsiktligt inte är tillåten och kontrollera att den förväntade blockeringen sker.
5. Testa DNS, Default Gateway och en typisk verksamhetsapplikation. Ett enda lyckat pingtest räcker inte.
6. Kontrollera hanteringsåtkomsten via den oberoende porten igen.
7. Om STP används får en redundant väg endast anslutas under ett underhållsfönster. Mät omkopplingstid och paketförlust.
8. Om HA används ska bryggan, medlemmarna, MAC-inlärningen och applikationerna testas igen efter ett kontrollerat rollbyte.

Ingen trafik och ingen loggpost

Om varken Allow eller Drop visas i Log Viewer kontrollerar du först bryggans specialfall:

• Saknar bryggan IP-adress?
• Träffar flödet en NAT-regel?
• Använder brandväggsregeln Web Proxy Filtering?
• Är SNAT-åsidosättningen för den här bryggan inställd på Original?
• Ser Packet Capture ramen på den ingående medlemmen men inte på den utgående?

Först därefter är det meningsfullt att leta efter vanlig felaktig regelordning eller problem med returvägen. Då undviker du att bemöta en ologgad blockering i bryggan med allt bredare Allow-regler.

VLAN eller EtherType slängs

Aktivera komponenten Bridge ACLs under System services > Log settings > Firewall. I Log Viewer kan du sedan filtrera på Log component > Bridge ACLs och dessutom på undertyperna ARP broadcasts, EtherType filtering eller VLAN filtering.

Vid VLAN-problem ska status för taggad respektive otaggad trafik, listan över tillåtna VLAN och switchportprofilen kontrolleras tillsammans. Vid EtherType-problem visar Packet Capture vilket fyrsiffrigt ID som faktiskt förekommer. Filtret och motparten måste motsvara samma dataväg.

Trafiken fungerar bara i en riktning

Ett enkelriktat flöde beror oftast på fel zon, en saknad regel, asymmetrisk routing eller en MAC-post som inte har lärts in. Jämför fram- och returvägen på båda medlemmarna i Packet Capture. Kontrollera därefter Rule ID, Source NAT, gateway och MAC-tabellen.

Loop eller instabila MAC-adresser

Många broadcastpaket, växlande MAC-associationer och instabila länkar tyder på en loop eller felaktigt inkopplad redundans. Koppla bort den andra vägen innan du ändrar fler filter. Kontrollera sedan switcharnas STP, SFOS STP, HA-kabeldragningen och de faktiska bryggmedlemmarna som en sammanhängande lösning.

En HA-design får inte bygga på antagandet att brandväggen samtidigt kan aktivera sitt eget STP-alternativ. Om switcharna ansvarar för loopskyddet måste redundanstestet visa att varken en loop eller en permanent blockerad produktionsväg uppstår.

Proceduren i Packet Capture på Sophos Firewall kan användas som komplement för en detaljerad koppling mellan interface, Rule ID, Status och Reason. Den fullständiga verifieringen av bryggan beskrivs ändå ovan på den här sidan.

Avancerade kontroller i Device Console

Den normala konfigurationen ska göras i WebAdmin. system bridge ger tillgång till ytterligare tre kontroller. Kommandona ersätter varken en saknad brandväggsregel eller en oklar lager 2-design. Dokumentera bryggnamn, Hardware name, medlemmar, port-ID:n, MAC-tabell, hanteringsväg och aktuell CLI-status före ändringar.

Hantera okänd icke-routbar trafik

bypass-firewall-policy gäller icke-routbar bryggtrafik som inte omfattas av någon Security Policy. SFOS skiljer mellan dynamic och static. Visa aktuell status med:

system bridge bypass-firewall-policy unknown-network-traffic show dynamic
system bridge bypass-firewall-policy unknown-network-traffic show static

De möjliga åtgärderna är allow och drop. allow vidarebefordrar uttryckligen den berörda trafiken utan någon Firewall Policy. SFOS 22-hjälpen anger varken något standardvärde eller den exakta avgränsningen mellan dynamic och static. En ändring bör därför endast göras i ett konkret ärende tillsammans med Sophos Support. Kontrollera sedan CLI-status och Packet Capture samt ett tillåtet och ett blockerat testflöde.

Den här inställningen är varken LAN Bypass eller en Stateful Firewall Bypass Rule. Den aktiverar ingen Fail-to-Wire-väg och undantar inte en känd anslutning från Stateful Inspection.

Lägg till statiska MAC-poster selektivt

Bridge Forwarding Table lär sig normalt MAC-adresser dynamiskt. static-entry binder en MAC-adress permanent till brygga, gränssnitt och port. Den officiella kommandomallen är:

system bridge static-entry [add | delete | show] [interface] {interface ID} [bridge name] [Port] {PortID} [macaddr] {MAC Address} [priority] [dynamic | static]

Hakparenteserna och klammerparenteserna beskriver syntaxen och ska inte kopieras. Kontrollera de faktiska ID:na med show och mappningen i WebAdmin innan du använder add. En felaktig eller inaktuell post kan styra ramar till fel port. Vid återställning tar du bort exakt den dokumenterade posten med delete. Testa sedan MAC-inlärningen, fram- och returvägen samt hanteringsåtkomsten igen.

Använd inte medlemsgränsen som skalningsmål

Visa den aktuella interna gränsen med:

system bridge max_bridge_members show

Device Console accepterar värden från 2 till 256 för max_bridge_members och har även funktionen reset:

system bridge max_bridge_members set limit <2-256>
system bridge max_bridge_members reset

De två officiella gränserna går inte att förena utan ytterligare förklaring. WebAdmin-hjälpen anger högst 64 medlemmar, medan Device Console-hjälpen dokumenterar värden från 2 till 256. Den förklarar inte hur uppgifterna förhåller sig till varandra. Ett värde över 64 kan därför inte betraktas som en tillåten produktionsdesign enbart med hänvisning till CLI-intervallet.

Dokumentera aktuell status med show före en ändring. Om standardvärdet användes tidigare återställer du med reset. Om en egen gräns var inställd återställer du exakt det värdet med set limit <föregående värde>. Bekräfta sedan den förväntade statusen med ännu en show.

Ta bort bryggan på ett säkert sätt

Dokumentera Object Usage, regler, NAT, VLAN, DHCP, routes, hosts, medlemszoner och hanteringsåtkomst före borttagningen. Skapa först en ersättningsväg och testa den med verklig trafik. Först därefter tar du bort produktionsberoenden, raderar bryggan och binder medlemmarna på nytt under kontrollerade former.

Efter borttagningen ska gateway, DNS, hantering, produktionsapplikationer, Firewall Rule ID och returväg kontrolleras igen. Ändringen är inte slutförd förrän resultaten motsvarar det dokumenterade utgångsläget.

Vanliga frågor