Konfigurera Sophos Firewall High Availability (HA)

High Availability, förkortat HA, kopplar samman två Sophos Firewalls till ett kluster. I de flesta miljöer är Active-Passive med QuickHA det bästa valet: En brandvägg hanterar trafiken och den andra tar över vid fel eller underhåll. Innan man börjar måste enheterna, firmware-build, licenserna, kabeldragningen och administrationsåtkomsten passa ihop.

Artikeln går från valet av HA-läge via konfigurationen till failover-test, drift och RMA. HA ersätter varken god nätverksdesign eller säkerhetskopior.

Välja HA-läge och arkitektur

I de flesta produktionsmiljöer är Active-Passive det bättre HA-alternativet. En brandvägg hanterar all trafik och den andra står redo att ta över vid fel eller underhåll. Designen är enklare, licensieringen billigare och beteendet vid fel lättare att förstå.

Active-Active är bara meningsfullt om man medvetet accepterar begränsningarna. Det är inte klassisk symmetrisk lastbalansering där båda brandväggarna är likvärdiga överallt i nätverket. Primary Firewall tar fortfarande emot trafiken och fördelar vissa anslutningar till Auxiliary Firewall. Alla tjänster och trafiktyper fördelas inte.

Snabb vägledning:

• Maximal stabilitet och enkel drift: Active-Passive.
• Använda den andra brandväggen utan separat skyddslicens: Active-Passive.
• Högre kapacitet behövs för vissa TCP-anslutningar: utvärdera Active-Active.
• Många VPN-, proxy-, RED-, NDR- eller specialfall: föredra Active-Passive.
• Liten eller medelstor miljö utan tydligt prestandaproblem: Active-Passive.
• Tydligt prestandakrav och lämplig licensiering för båda enheterna: Active-Active efter test.

De två Sophos Techvids visar konfiguration och rollbyte visuellt:

Vad High Availability innebär

Ett Sophos Firewall HA-kluster består av två brandväggar. Enheterna utbyter Heartbeats, enhetsstatus, anslutningsinformation och konfigurationsdata över en dedikerad HA-Link. Konfigurationen synkroniseras från Primary Firewall till Auxiliary Firewall.

HA skyddar mot typiska fel:

• fel på Primary Firewall
• ström- eller hårdvarufel
• fel på ett övervakat gränssnitt
• program- eller tjänstefel som gör enheten obrukbar
• planerade firmware-uppdateringar
• planerat rollbyte vid underhåll

HA löser däremot inte alla problem:

• Ett felaktigt regelverk förblir felaktigt även i klustret.
• Fel på en gemensam switch kan påverka båda brandväggarna samtidigt.
• Felaktig VLAN-design eller routing korrigeras inte automatiskt.
• Loggar och rapporter synkroniseras inte fullständigt mellan brandväggarna.
• Säkerhetskopior är fortfarande obligatoriska.

Den som planerar HA bör först ha ordning på zoner, gränssnitt, VLAN, LAG och bryggor. Se Planera och konfigurera zoner och gränssnitt på Sophos Firewall.

Active-Passive eller Active-Active

Active-Passive

I Active-Passive hanterar en brandvägg all produktionstrafik. Den andra är passiv och tar över först när den aktiva brandväggen fallerar eller när failover utlöses manuellt eller av underhåll.

Typiska egenskaper:

• Primary Firewall hanterar trafiken.
• Auxiliary Firewall står i standby.
• Sessioner synkroniseras när protokollet och tjänsten stöder det.
• För hårdvaruenheter behöver endast den licensbärande enheten skyddsabonnemangen.
• Auxiliary Firewall tar över samma virtuella MAC-adress vid failover.
• Nätverksenheter behöver normalt inte lära om sina grannar.

Active-Passive är oftast bäst för vanliga företagsmiljöer, filialer, datacenter och miljöer där stabilitet är viktigare än en möjlig prestandavinst.

Active-Active

I Active-Active hanterar båda brandväggarna trafik. Arkitekturen är ändå asymmetrisk: Primary Firewall tar emot trafiken och avgör om den ska hantera anslutningen själv eller skicka den till Auxiliary Firewall.

Sophos använder bland annat käll-IP-adressen för fördelningen: TCP-anslutningar från jämna källadresser hanteras vanligtvis av Primary, medan udda kan gå till Auxiliary. Vidarebefordrade eller översatta TCP-anslutningar fördelas. Icke-TCP-trafik, SD-RED, tunnlad trafik och Layer 7-anslutningar via DPI eller proxy — inklusive SMTP Proxy, HTTPS, skannad FTP och H.323 — fördelas inte. Sophos stöder inte externa load balancers framför klustret för denna HA-logik.

Båda noderna behöver lämpliga licenser och lagrar lokalt loggarna för trafiken de hanterar. Active-Active är därför bara meningsfullt med ett tydligt prestandamål och bevis för att den relevanta trafiken faktiskt fördelas. För ren hög tillgänglighet är Active-Passive oftast bättre.

Roller, status och failover

Roller i HA-klustret

• Primary: Enheten som hanterar klustrets centrala konfiguration. I båda HA-lägena tar Primary emot trafiken.
• Auxiliary: Den andra enheten i klustret. Den synkroniserar konfigurationen från Primary och tar över vid behov.
• Initial primary: Enheten som startades som Primary vid konfigurationen. I Active-Passive är den normalt också licensbärande.
• Preferred primary: Den enhet som ska återgå till rollen Primary efter failover när den åter är stabilt tillgänglig.

Statusvärden under drift

• Active: Enheten hanterar trafik.
• Passive: Enheten är redo men hanterar ingen produktionstrafik i Active-Passive.
• Standalone: Enheten ser inte den andra noden eller HA är inte helt aktivt. Vid fel på HA-Link kan båda enheterna bli Standalone.
• Faulty: Enheten är inte tillräckligt frisk för att delta normalt i klustret.

Virtuell MAC-adress

Sophos Firewall använder virtuella MAC-adresser för produktionsgränssnitt i HA-klustret. Endast Primary besvarar ARP-förfrågningar för klustret. Vid failover tar Auxiliary över den virtuella MAC-adressen. Det ger stabilare åtkomst för switchar, routrar och klienter eftersom tilldelningen mellan IP och MAC inte ändras i grunden.

Cluster ID är viktig eftersom den används för den virtuella MAC-adressen. Om flera HA-kluster körs i samma Layer 2-miljö måste varje kluster ha ett unikt Cluster ID. Annars kan MAC-konflikter uppstå.

Vad som synkroniseras

• Firewallregler, Policies, objekt, routing och CLI-konfiguration synkroniseras från Primary till Auxiliary.
• Aktiva sessioner synkroniseras beroende på protokoll och tjänst.
• Secure Storage Master Key och inloggningsuppgifter för WebAdmin synkroniseras.
• Dedicated HA link synkroniseras inte som en vanlig produktionskonfiguration för ett gränssnitt.
• Peer Admin Port hanteras separat och synkroniseras inte som ett vanligt gränssnitt.
• Loggar och rapporter synkroniseras inte mellan enheterna.

Beteende vid failover

Failover kan utlösas av flera händelser:

• uteblivna Heartbeats över HA-Link
• fel på en övervakad port
• strömavbrott
• hårdvarufel
• program- eller tjänstefel
• planerat rollbyte
• firmware-uppdatering

Om en enskild Node startar i Failsafe-läge dokumenteras först dess roll och peerens tillstånd. Kontrollera Sophos Firewall i Failsafe-läge visar det skrivskyddade diagnoskommandot och förklarar varför båda Nodes inte ska startas om utan samordning och HA inte ska avaktiveras på måfå.

Heartbeats går över den dedikerade HA-Link. Mycket korta intervall används som standard. Om flera Heartbeats i följd uteblir betraktas den andra noden som otillgänglig. Brandväggen kontrollerar därefter tillståndet och genomför rollbytet.

Vid failover fortsätter många anslutningar eller återupprättas snabbt. Failover är dock inte helt transparent för alla program. Särskilt stateful TCP-anslutningar, webbsessioner, proxyanslutningar och vissa VPN-scenarier kan avbrytas kort eller behöva återupprättas.

Tjänster med stöd och begränsningar

Sophos HA stöder de flesta brandväggstjänster, men vissa har särskilda egenskaper.

• Firewallregler och NAT synkroniseras. I Active-Active måste man veta vilken nod som hanterar anslutningen.
• VPN fungerar i många HA-scenarier, men alla sessionstyper växlar inte utan avbrott. IPsec kan ta över stateless UDP/ICMP bättre än stateful TCP.
• Web Protection fungerar i klustret. I Active-Active kan varningar komma från båda noderna.
• Email Protection kan vara nodberoende för karantän och frisläppning eftersom varje enhet lagrar egna data för e-posttrafiken den hanterar.
• Synchronized Application Control är inte lämpligt för Active-Active om funktionen inte stöds i den använda SFOS-versionen.
• NDR Essentials bör bara planeras med Active-Passive i HA-miljöer.
• sFlow körs endast på Primary i HA-miljöer.
• Rapporter skapas lokalt per enhet. Sammanställda rapporter hanteras bättre med Sophos Central Firewall Reporting.
• Cellular WAN måste stängas av för HA.
• XGS Wi-Fi-modeller stöder inte HA.

Om rapportering eller logglagring är viktig bör man tidigt planera en extern Syslog-server eller Sophos Central Firewall Reporting. Se Aktivera Central Firewall Reporting.

Krav och nätverksdesign

Innan införandet måste HA-kraven jämföras noggrant med miljön. Modellikhet, firmware, gränssnitt, Cellular WAN och virtuella plattformar är särskilt viktiga eftersom små avvikelser kan få stor effekt.

Hårdvara och modellkompatibilitet

• Enhetsmodell: Båda brandväggarna måste vara samma XGS-modell, exempelvis XGS 2100 med XGS 2100.
• Hårdvarurevision: Olika hårdvarurevisioner är möjliga med samma XGS-modell.
• XGS Wi-Fi-modeller: Stöds inte, exempelvis XGS 126w och XGS 136w.
• Flexi Port Module: Om expansionsmoduler används måste antalet Flexi Ports vara samma på båda enheterna.
• Firmware: Båda enheterna måste köra samma SFOS-version inklusive Maintenance Release och build.
• Hårdvara plus virtuell enhet: Kan inte bilda ett HA-par.

SFOS 22 stöder inte längre hårdvara i XG- eller SG Series. Före migrering till SFOS 22 måste sådana enheter ersättas med en XGS-enhet som stöds eller en lämplig virtuell plattform.

Virtuella enheter och programvaruenheter

Virtuella enheter och programvaruenheter måste också matcha noggrant.

• Plattform: Samma enhetstyp och SFOS-plattform.
• Hypervisor: Samma Hypervisor-typ.
• Resurser: Samma antal CPU-kärnor, jämförbara resurser och samma antal nätverksgränssnitt.
• Firmware: Samma SFOS-version inklusive build.
• MAC-adresser: I virtuella miljöer kan alternativet för MAC-adresser som tilldelas av Hypervisor vara relevant för att slippa Promiscuous Mode. En ändring orsakar dock driftavbrott.

Molndistributioner

I molnmiljöer gäller ytterligare plattformskrav. Routing, virtuella gränssnitt, IP-adresser, Security Groups, UDR och molnspecifika failover-mekanismer måste passa plattformens design. Vanlig enhets-HA kan inte överföras till Azure, AWS eller andra molnmiljöer utan granskning.

Om en Sophos Firewall körs i molnet bör man före HA-planeringen kontrollera aktuell Sophos-dokumentation för plattformen och molnets nätverksarkitektur.

Licensiering och registrering

HA-licensieringen skiljer sig mellan plattformar och HA-lägen. Tre frågor är avgörande: Är det maskinvara eller Virtual/Software? Används Active-Passive eller Active-Active? Vilken enhet är Initial Primary och därmed licensbärare för klustret? Dessa uppgifter måste jämföras med licensstatus, serienummer och målläge före införandet.

De viktigaste licenspunkterna:

• Base Firewall: HA kräver en Base Firewall-licens. Hårdvaruenheter har den som standard, medan Virtual/Software måste vara licensierade på rätt sätt.
• Maskinvara i Active-Passive: Endast Initial Primary behöver produktionsabonnemangen. Auxiliary Firewall får en kopia och kan hantera trafik efter failover.
• Maskinvara i Active-Active: Båda brandväggarna behöver egna lämpliga licenser. Licenstyperna måste stämma, men slutdatumen får skilja sig.
• Active-Passive Virtual/Software: Endast Primary behöver licenserna, inklusive Base Firewall.
• Active-Active Virtual/Software: Båda enheterna behöver egen Base Firewall och lämpliga övriga skyddslicenser.
• Registrering av hårdvara: Båda hårdvaruenheterna måste vara registrerade i Sophos Central och kunna synkronisera licenser före HA-konfigurationen.
• Registrering av Virtual/Software Active-Passive: Enligt Sophos är endast Primary registrerad i Active-Passive Virtual/Software.
• Sophos Central Management: Licenssynkronisering och registrering innebär inte automatiskt hantering via Sophos Central Firewall Management. Det kräver ett lämpligt extra abonnemang.
• RMA och support: Supportstatus är viktig vid hårdvarubyte och Advance Replacement. För maskinvara i Active-Passive anger Sophos Enhanced Plus Support på Primary som ett relevant krav för Advance Hardware Replacement. I Active-Active måste supportstatus vara lämplig på båda enheterna.

Viktigt: Initial Primary är särskilt viktig i Active-Passive eftersom den bär klusterlicensen. I HA-vyn markeras motsvarande enhet som licensbärare för klustret. Dokumentera den entydigt i driftshandboken.

Om licenserna skiljer sig i Active-Active stoppas lastbalanseringen i upp till tre dagar. Om skillnaden kvarstår inaktiverar brandväggen HA. Vid första konfigurationen aktiveras inte Active-Active med licenser som inte stämmer.

Initial Primary måste synkronisera licenserna minst en gång inom 90 dagar. För hårdvara stoppas annars berörda skyddsabonnemang, medan Base Firewall och Enhanced Support förblir aktiva. För Virtual/Software inaktiveras Base Firewall-licensen, HA stängs av och övriga skyddsfunktioner blir inaktiva. Onlinelicensierade kluster behöver DNS, korrekt systemtid, routing och internetåtkomst till Sophos licenstjänster. Isolerade kluster använder i stället den dokumenterade manuella Air-Gap-licensieringen.

Driftdokumentationen bör minst ange:

• vilken enhet som är Initial Primary
• vilka serienummer eller Appliance IDs som tillhör klustret
• vilka licenser som är aktiva på respektive enhet
• när licenserna senast synkroniserades
• vilken supportnivå som finns för RMA eller Advance Replacement
• vem som godkänner licensändringar, Renewals och RMA-processer

Nätverkskrav

• HA-Link: Dedikerad anslutning mellan brandväggarna, helst direkt med Ethernet-kabel.
• HA-Link-zon: DMZ-zon med SSH aktiverat för zonen.
• HA-Link-IP-adresser: Statiska adresser i samma subnät men olika adresser.
• HA-Link-kvalitet: Hög bandbredd, låg latens och ingen paketförlust.
• Switchar: Aktivera RSTP på switchar som är anslutna till brandväggsportarna.
• Monitored Ports: Övervaka bara portar som verkligen är anslutna och kritiska.
• Cellular WAN: Stäng av för HA.
• Peer Admin Port: Planera separat så att Auxiliary Firewall förblir åtkomlig.
• Gränssnittsadresser: Active-Active kräver statiska IP-adresser på alla gränssnitt. Active-Passive tillåter DHCP eller PPPoE, men dessa anslutningar har ingen sessionsövertagning.

HA-Link hanterar ingen vanlig klient- eller servertrafik. Den används bara för Heartbeats, status, sessions- och konfigurationssynkronisering samt Active-Active-fördelning. Den är ändå kritisk. Om HA-Link fallerar kan båda brandväggarna tro att de är Primary. Detta Split-Brain-scenario måste undvikas.

Peer Admin Port ger separat administrativ åtkomst till Auxiliary Firewall. Administrationsportarna på båda enheterna måste ligga i samma subnät men ha olika IP-adresser. QuickHA använder automatiskt det gränssnitt som den aktuella WebAdmin-sessionen går över. Efter HA-konfigurationen når man Auxiliary endast via Peer Admin-adressen från ett lämpligt nät.

Portar och gränssnitt

• Dedicated HA link: Används för Heartbeat, status samt konfigurations- och sessionssynkronisering. Anslut direkt eller via en mycket tillförlitlig switch. Använd inte för produktionstrafik.
• Monitored ports: Övervakar kritiska produktionslänkar. Övervaka WAN och viktiga DMZ- eller Core-uplinks, men välj inte oanvända portar.
• Peer Admin Port: Ger åtkomst till Auxiliary WebAdmin. Planera och dokumentera separat; klienten måste finnas i rätt subnät.
• Produktionsgränssnitt: LAN, WAN, DMZ, VLAN och LAG ska kabelanslutas identiskt och utformas likvärdigt på båda brandväggarna.

Fysiska gränssnitt, VLAN och LAG kan användas som Dedicated HA link. Brygggränssnitt och Alias IP-adresser kan inte användas. QuickHA kan kombinera upp till fyra obundna fysiska gränssnitt i en HA redundant link; för ett redan konfigurerat LAG måste överordnade gränssnitt vara uppbyggda på samma sätt på båda enheterna.

Viktigt: Dedicated HA link och Monitored Port får inte vara samma gränssnitt. Om ett gränssnitt redan används i produktionskonfigurationen och ändå väljs som HA-Link kan brandväggen ändra eller ta bort beroende konfigurationer. HA-Link bör därför vara ledig och dokumenterad i förväg.

Nätverksdesign

Båda brandväggarna måste kunna ta över samma nätverksposition vid fel. Produktionsgränssnitt, VLAN Trunks, LAG, switchportar och operatörsanslutningar ska därför vara likvärdigt kabelanslutna på båda sidor. WAN-redundans, SD-WAN och operatörsfailover är separata uppgifter; HA ersätter dem inte.

• Anslut om möjligt Dedicated HA link direkt. Över switchar måste vägen vara stabil, ha låg latens och vara fri från paketförlust.
• Aktivera RSTP på berörda switchar och konfigurera VLAN, Trunks och LAG identiskt på båda sidor.
• Övervaka endast permanent anslutna WAN-, Core- eller DMZ-uplinks. En avsiktligt frånkopplad Monitored Port utlöser annars failover.
• VLAN och LAG stöds men måste använda samma överordnade gränssnitt på båda noderna. Bridge Mode fungerar men är mer komplicerat att felsöka än Gateway Mode.
• Testa VPN-, RED- och Remote-scenarier separat eftersom alla sessioner inte tas över transparent.
• Begränsa administrationsåtkomst och Device Access medvetet. Se Skydda åtkomsten till Sophos Firewall: konfigurera Device Access korrekt.

För Active-Active måste man dessutom veta vilken flaskhals den trafik som faktiskt kan fördelas ska lösa. Om licensiering, tjänster och felsökning på båda noderna inte är klarlagda är Active-Passive det bättre valet.

Varning: Vid Split-Brain anser båda brandväggarna att de är ansvariga. Det kan ge dubbla IP- och MAC-adresser och produktionsavbrott. Om HA-Link fallerar, bestäm först vilken nod som ska vara aktiv och stäng av den andra under kontrollerade former eller koppla bort den från produktionsnätet.

Förbereda konfigurationen

HA-konfiguration ska inte improviseras i produktionsnätet. Följande förberedelser sparar tid senare.

Förbereda båda brandväggarna

• Uppdatera båda brandväggarna till samma SFOS-version inklusive build.
• Kontrollera licens- och registreringsstatus.
• Stäng av Cellular WAN.
• Säkerställ att modellerna är kompatibla.
• Kontrollera Flexi Port-utrustningen.
• Dokumentera gränssnitt och switchportar.
• Bestäm port för HA-Link.
• Anslut HA-länken direkt med kabel eller kontrollera switchvägen.
• Planera DMZ-zon och SSH-åtkomst för HA-Link.
• Dokumentera administrativ åtkomst till båda enheterna.
• Skapa en säkerhetskopia av befintlig konfiguration.
• Om LINCE behövs, gör läget identiskt på båda enheterna före HA.

FIPS följer en annan ordning än LINCE. FIPS 140-3-läget aktiveras först på standalone Primary, vilket utför en fabriksåterställning; under den efterföljande HA-konfigurationen aktiverar Sophos automatiskt FIPS på Auxiliary.

Säkerhetskopior är inte valfria med HA. En kopia bör finnas före konfiguration, firmware-uppdateringar och större ändringar av gränssnitt. Se Skapa eller återställa en säkerhetskopia på Sophos Firewall.

Kontrollera även följande före Initiate HA:

• Admin-portar i samma subnät men med olika IP-adresser: Annars kan HA inte byggas korrekt eller Auxiliary bli otillgänglig.
• Dedicated HA link utan produktionsberoenden: HA kan ändra gränssnittets IP-adress och beroende konfigurationer.
• Monitored Ports anslutna på båda enheterna: En oansluten Monitored Port kan hindra klustret eller omedelbart utlösa failover.
• Unikt Cluster ID: Flera HA-kluster i samma Layer 2-område behöver olika virtuella MAC-adresser.
• Dokumenterad säkerhetskopia, SSMK och firmware-build: Klustret måste kunna återskapas vid återställning, RMA eller ominstallation.

Fastställa LINCE före HA

Sedan SFOS 21.5 MR1 kan LINCE varken aktiveras eller inaktiveras efter att ett HA-kluster har skapats. Om certifieringen behövs ska följande kommando köras i Device Console på båda ännu fristående brandväggarna.

Varning: Säkerställ först en alternativ administrativ åtkomst via WebAdmin eller den lokala konsolen. Kommandot aktiverar LINCE, startar om SSH-tjänsten och kopplar från befintliga SSH-sessioner.

system certification lince enable

Kontrollera därefter LINCE-status på båda enheterna och skapa först sedan HA. Vid återställning måste säkerhetskopian och målklustret ha samma LINCE-status.

QuickHA eller Interactive mode

• QuickHA: Standardfallet. Snabbt, robust och tillräckligt för de flesta Active-Passive- och Active-Active-konfigurationer.
• Interactive mode: Lämpligt när Admin Ports, HA-Link-adresser, Cluster ID, Monitored Ports och detaljvärden måste anges medvetet före uppbyggnaden.

QuickHA frågar först bara efter roll, Node Name, Passphrase och Dedicated HA link. Passphrase måste vara 10 till 20 tecken och innehålla minst en versal, en gemen, en siffra och ett specialtecken. Den används en gång för att skapa SSH-nycklar och raderas därefter. Vid enhetsbyte måste HA därför inaktiveras och konfigureras om.

Stegen följer Sophos officiella HA-konfiguration men är formulerade som en praktisk checklista. Vid produktionsändringar ska man inte bara klicka igenom guiden utan dokumentera roller, HA-Link, administrativ åtkomst, säkerhetskopia, licensstatus och återställningsväg i förväg.

Konfigurera HA

Active-Passive med QuickHA

1. Förbereda Primary Firewall

1. Logga in på WebAdmin på den blivande Primary Firewall.
2. Gå till System services > High availability.
3. Välj Primary (active-passive) som läge.
4. Använd QuickHA.
5. Ange valfritt ett Node Name, exempelvis FW01.
6. Ange en HA Passphrase på 10 till 20 tecken med versal, gemen, siffra och specialtecken.
7. Spara Passphrase säkert eftersom den strax behövs på Auxiliary Firewall.
8. Välj Dedicated HA link.
9. Starta Initiate HA.

Anmärkningar:

• Om QuickHA använder ett obundet gränssnitt tilldelar Sophos det DMZ-zonen och som standard 169.254.192.1. SSH aktiveras automatiskt för zonen.
• Brandväggen tar bort beroende konfigurationer från valt HA-länkgränssnitt. Det måste därför vara fritt från produktionsberoenden.

2. Förbereda Auxiliary Firewall

1. Logga in på den blivande Auxiliary Firewall.
2. Gå till System services > High availability.
3. Välj Auxiliary som roll.
4. Använd QuickHA.
5. Ange valfritt ett Node Name, exempelvis FW02.
6. Ange samma HA Passphrase.
7. Välj samma HA-Link-port som på Primary-sidan.
8. Starta Initiate HA.

Efter uppbyggnaden synkroniserar Primary Firewall konfigurationen till Auxiliary Firewall. Många lokala inställningar på Auxiliary skrivs över. Auxiliary bör därför inte samtidigt konfigureras som en fristående produktionsbrandvägg före HA-konfigurationen.

3. Kontrollera avancerade inställningar

Kontrollera följande efter att klustret har skapats:

• HA-status för båda noderna
• roll och status uppe till höger i WebAdmin
• Dedicated HA link
• Monitored Ports
• Peer Admin Port
• Preferred primary
• Keepalive interval och Attempts
• licensbärare i Active-Passive
• Sophos Central-registrering om den används

4. Ange Monitored Ports

Monitored Ports avgör om ett gränssnittsfel utlöser failover. Typiska kandidater:

• WAN-uplink
• Core LAN-uplink
• viktiga DMZ- eller server-uplinks

Övervaka inte portar som ibland avsiktligt är frånkopplade, saknar kabel eller bara används i valfria scenarier. En felaktigt vald Monitored Port orsakar ofta oväntad failover eller ett kluster som inte startar.

Active-Active med QuickHA

Active-Active konfigureras på liknande sätt men med ett annat mål. Båda brandväggarna måste först ha lämpliga licenser.

Förloppet motsvarar Active-Passive, men på FW01 väljer man Primary (active-active). Båda enheterna måste först vara registrerade, ha samma SFOS-build och lämpliga licenstyper; alla gränssnitt måste ha statiska IP-adresser. Övervakning och felsökning måste täcka båda noderna, och den relevanta trafiken måste dra nytta av TCP-fördelningen som beskrivits ovan.

Testa efter konfigurationen

I Active-Active måste mer än HA-status testas:

• Fördelas anslutningar till båda noderna?
• Syns loggar på båda enheterna?
• Fungerar VPN-anslutningar efter ett rollbyte?
• Fungerar Web Protection, IPS, Application Control och relevanta Security Features?
• Finns program som påverkas av det asymmetriska beteendet?
• Skapas rapporter och varningar som förväntat?

Interactive mode

Interactive mode är lämpligt när den automatiska QuickHA-logiken inte ger tillräcklig kontroll.

Typiska skäl:

• fasta HA-Link-IP-adresser ska användas
• Peer Admin Port måste definieras exakt
• Cluster ID ska anges medvetet
• flera HA-kluster finns i samma Layer 2-miljö
• virtuella enheter ska använda bestämda MAC-alternativ
• ett strikt kontrollerat införande krävs

I Interactive mode konfigureras Auxiliary först och därefter Primary. Då hinner identifieringen av den andra noden på Primary inte löpa ut medan den förbereds.

1. Konfigurera Auxiliary

1. Gå på FW02 till System services > High availability.
2. Välj Initial device role > Auxiliary och HA configuration mode > Interactive mode.
3. Ange Node Name och en Passphrase enligt reglerna ovan.
4. Välj den lediga DMZ-porten som Dedicated HA link. Brandväggen tar bort befintliga beroende konfigurationer för detta gränssnitt.
5. Spara och vänta på bekräftelse att Auxiliary-konfigurationen har tillämpats.

2. Konfigurera Primary

1. Välj på FW01 Primary (active-passive) eller Primary (active-active) och Interactive mode.
2. Ange ett unikt Cluster ID och Node Name.
3. Ange Passphrase från FW02.
4. Ange samma Dedicated HA link och den statiska HA-Link-IP-adressen för Auxiliary.
5. Välj kritiska Monitored ports.
6. Ange administrationsgränssnitt och en egen IP-adress för FW02 under Peer administration settings.
7. Välj vid behov MAC-adressen som tilldelas av värdsystemet eller Hypervisor för virtuella enheter. En senare ändring orsakar driftavbrott.
8. Ange Preferred primary och välj Initiate HA.

Ändra Keepalive-värden efter uppbyggnaden endast med dokumenterat skäl. Som standard skickar brandväggen ett Heartbeat var 250:e millisekund och bedömer den andra noden som otillgänglig efter 16 uteblivna Heartbeats.

Validera klustret

Efter konfigurationen ska HA-klustret kontrolleras systematiskt.

Kontroll i WebAdmin

1. Logga in på Primary Firewall.
2. Kontrollera HA-status uppe till höger.
3. Gå till System services > High availability.
4. Kontrollera roller, status, serienummer och läge.
5. Säkerställ att klustret är synkroniserat.
6. Kontrollera i Active-Passive vilken enhet som bär klusterlicensen.

Kontroll i CLI

Följande kommando i Device Console läser klustrets roller, status och synkronisering utan att ändra konfigurationen:

system ha show details

Vilken enhet som är licensbärande Initial Primary kontrolleras i första hand under System services > High availability. I ett dokumenterat supportfall kan även följande interna skrivskyddade värde i Advanced Shell hjälpa:

nvram get "#li.master"

YES står vanligtvis för Initial Primary och NO för Auxiliary. Sophos dokumenterar inte detta interna Advanced Shell-kommando som ett normalt administratörsgränssnitt; HA-vyn är därför referensen.

Om Shell-åtkomst inte har förberetts hjälper Anslut till Sophos Firewall via SSH.

Funktionstest

• Testa en klient från LAN till internet.
• Testa åtkomst till interna servrar.
• Testa VPN.
• Testa DNAT- eller WAF-scenarier.
• Testa DNS och DHCP om brandväggen tillhandahåller tjänsterna.
• Kontrollera loggar i Log Viewer.
• Testa HA-rollbyte i ett underhållsfönster.
• Dokumentera därefter roller, status och sessionsbeteende.

Drift och underhåll

Löpande övervakning

Övervaka HA- och rollstatus, Dedicated HA link, Monitored Ports, licenser, firmware, CPU, RAM, lagring och centrala tjänster. Varningar ska gå till Sophos Central, e-post eller befintlig övervakning.

Lagring och hårdvara ska granskas separat på båda noderna. Lokala rapporter, loggfiler och SSD-status kan skilja sig. Se Kontrollera lagringsutrymme och hantera rapporter på Sophos Firewall och Kontrollera SSD-hälsa på Sophos Firewall med SMART.

Loggar och rapporter

Varje nod skriver loggar för trafiken den hanterar. I Active-Active måste man därför kontrollera båda enheterna. Sophos Central Firewall Reporting eller Syslog passar för gemensam analys. Lokala filer beskrivs i Felsökning av Sophos Firewall: tjänster och loggar.

Driftinstruktion för HA

Dokumentera minst följande i driftinstruktionen:

• serienummer, plats, Rack-position och roll för båda enheterna
• Dedicated HA link, Peer Admin Port, Cluster ID och Monitored Ports
• Preferred primary och förväntat beteende efter failover
• licensbärare, supportstatus och kontaktväg för RMA
• process och ansvar för firmware-uppdatering, säkerhetskopiering, ominstallation, hårdvarubyte, loggar och supportärenden

Om bara WebAdmin på en nod hänger betyder det inte automatiskt att hela HA-klustret är felaktigt. Kontrollera om omstart av WebAdmin GUI eller en kontrollerad omstart av en tjänst räcker innan failover eller omstart utlöses.

Ändringar i klustret

Ändra regler, gränssnitt och Policies endast på Primary. Före ändringar av gränssnitt, VLAN, LAG, zoner, routing, NAT, VPN, Device Access eller SD-WAN:

• skapa en säkerhetskopia
• definiera underhållsfönster
• kontrollera HA-status
• uppdatera dokumentationen
• bestäm återställningsväg
• testa därefter synkronisering och trafik

Firmware-uppdateringar och säkerhetskopior

Firmware-uppdateringar i HA-miljöer

Firmware-uppdateringar startas på Primary Firewall. Enheterna uppdateras i turordning och klustret kan byta roller under tiden.

Typiskt förlopp:

1. Starta uppdateringen på Primary Firewall.
2. Auxiliary Firewall uppdateras.
3. Auxiliary Firewall startar om och tar tillfälligt över.
4. Tidigare Primary uppdateras.
5. Tidigare Primary startar om.
6. Om Preferred primary är aktivt kan klustret återgå till den föredragna enheten.

Firmware-uppdateringar hör ändå hemma i ett underhållsfönster. Även om processen är utformad för minimala driftavbrott kan enskilda sessioner, VPN-anslutningar eller specialprogram störas tillfälligt.

Se Firmware-uppdatering för Sophos Firewall – förberedelser och Best Practices.

Pattern Updates

Pattern Updates installeras på Primary och synkroniseras automatiskt till Auxiliary. Det gäller även miljöer där uppdateringar styrs eller installeras utan internetanslutning.

I ett isolerat HA-kluster måste man före varje manuell Pattern- eller licensuppdatering veta vilken nod som är Initial Primary och vilken som för närvarande är Primary. Air-Gap-processen beskrivs i Driva Air-Gap-licensiering och Pattern Updates på Sophos Firewall.

Säkerhetskopiering och återställning

Säkerhetskopiering och återställning har särskilda egenskaper i HA-miljöer:

• Skapa säkerhetskopior regelbundet och före varje större ändring.
• Återställningen utförs på aktuell Primary Firewall.
• Efter återställningen avregistreras båda brandväggarna från Sophos Central och måste registreras igen.
• Återställningen orsakar omstart och driftavbrott, inte vanlig failover.
• Om en säkerhetskopia utan HA-konfiguration återställs till ett HA-kluster inaktiveras HA och måste byggas upp igen.
• När LINCE är aktiverat måste säkerhetskopian och målklustret ha samma LINCE-status.

Om klustret använder Sophos Central Synchronized Security måste HA-paret tas bort från Central-hanteringen innan enheten returneras genom RMA-processen. Efter bytet registreras det nya HA-klustret i Central på nytt. Det förhindrar konflikter i synkroniseringen av serienummer och licenser med den gamla enheten som fortfarande är registrerad.

Byta Auxiliary efter RMA

Byte eller ominstallation av en nod orsakar ett planerat avbrott. Följande processer gäller Active-Passive; för Active-Active måste den exakta processen planeras med Sophos Support.

1. Kontrollera att ersättningsenhetens modell och hårdvarurevision är lämpliga och installera exakt samma firmware-build som på den fungerande Primary-enheten.
2. Registrera ersättningsenheten i Sophos Central och överför licensen från den defekta Auxiliary-enheten.
3. Flytta kablarna från den felaktiga enheten till ersättningsenheten.
4. Inaktivera HA på den fungerande Primary-enheten under System services > High availability.
5. Kontrollera i Advanced Shell att msync är stoppad:

service -S | grep msync

Förväntat resultat är UNTOUCHED eller STOPPED. Kommandot ändrar inget; annan status betyder att HA ännu inte bör byggas upp igen. Konfigurera därefter den fungerande enheten som Primary och ersättningsenheten som Auxiliary.

Byta Primary efter RMA

1. Hämta en aktuell säkerhetskopia från den fungerande Auxiliary-enheten och avregistrera enheten från Sophos Central.
2. Installera samma firmware-build på ersättningsenheten, registrera den i Sophos Central och överför licensen från den defekta Primary-enheten.
3. Återställ säkerhetskopian på ersättningsenheten.
4. Flytta kablarna från den fungerande Auxiliary-enheten till ersättningsenheten. Från denna punkt hanterar ersättningsenheten trafiken som fristående brandvägg.
5. Fabriksåterställ tidigare Auxiliary, registrera den på nytt i Sophos Central och anslut avsedda kablar.
6. Bygg upp HA igen med ersättningsenheten som Primary och den återställda enheten som Auxiliary.

Varning: Återställning av säkerhetskopia, Factory Reset och kabelflytt orsakar driftavbrott. Serienummer, Initial Primary, firmware-build, licensöverföring, Central-status och återställningsväg måste vara dokumenterade före start.

Se Installera om Sophos Firewall OS med USB-minne. Vid misstänkt hårdvarufel eller RMA bör även Förbered hårdvarufel och RMA för Sophos korrekt planeras.

Felsökning

Vid djupa felbilder bör man arbeta strukturerat: kontrollera först status, HA-Link, Monitored Ports, firmware och licensstatus. Gå därefter vidare till specialfall eller tillverkarens anvisningar. Då blir det tydligt om felet verkligen gäller HA eller orsakas av licens, gränssnitt, firmware eller övervakning.

Viktiga loggar och diagnosplatser

• HA-status: System services > High availability.
• Event Logs: Log viewer > System.
• Troubleshooting Logs: Monitor & Analyze > Logs > Troubleshooting logs eller via SSH under /log.
• HA-detaljer i CLI: Se den enskilt beskrivna CLI-kontrollen under Validera klustret.
• Gränssnittsproblem: show network interfaces, ifconfig, dmesg i lämpliga diagnosfall.
• Licensbärare: System services > High availability.

Följande filer är särskilt användbara för första analysen:

• ha.log: fel vid uppbyggnad, lyckad HA-uppbyggnad och statusbyten.
• ha_pair.log: identifiering av den andra noden i QuickHA.
• ha_tunnel.log: SSH-tunnel över Dedicated HA link.
• msync.log: synkronisering av HA-konfigurationen.
• ctsyncd.log: synkronisering av Conntrack-sessioner.
• filesync.log: tjänsterelaterad filsynkronisering, exempelvis för dynamiska rutter eller DHCP.

Varje nod lagrar bara loggar och rapporter för trafiken den själv hanterar. Logga in på Auxiliary via dess Peer Admin-adress eller hämta loggfiler via SSH från denna nod.

Vid djupare analys hjälper CLI-felsökning på Sophos Firewall: viktiga kommandon.

Typiska HA-fel

• Klustret bildas inte, firmwareversioner eller buildnummer skiljer sig: Kontrollera version på båda enheterna och uppdatera båda till identisk SFOS-version.
• Klustret bildas inte, modell eller enhet passar inte: Kontrollera modell och serienummer. Använd endast kompatibla identiska XGS-modeller för HA med hårdvara.
• HA could not be enabled: Dedicated HA link kan vara frånkopplad eller den andra noden otillgänglig. Kontrollera portstatus, kabel, switch och Ping till HA-Link-IP och stabilisera sedan kabeldragning eller HA-Link.
• HA-Link down: Kabel, switchport, VLAN eller LAG kan vara felaktigt. Kontrollera gränssnittsstatus, Speed/Duplex, VLAN Trunk och LAG-medlemmar.
• Båda enheterna blir Standalone: HA-Link har fallerat och Split-Brain-risk finns. Kontrollera fysisk HA-Link och switchväg, stäng av en enhet under kontrollerade former, reparera HA-Link och starta sedan igen.
• Auxiliary WebAdmin är inte åtkomligt: Peer Admin Port, subnät, route eller Device Access stämmer inte. Kontrollera Admin Port-IP och åtkomst från administrationsnätet.
• Validation failed for HA interface IP: Admin Ports eller HA-Link-adresser ligger inte i förväntat subnät. Kontrollera IP-adresser och /log/syslog.log och korrigera adresseringen.
• Failover sker oväntat: En Monitored Port har ofta fallerat eller valts fel. Kontrollera Monitored Ports och switchstatus och övervaka bara verkligt kritiska, stabila portar. Om den berörda noden faktiskt startade om och inte bara bytte roll ska den oväntade omstarten kontrolleras för den noden.
• Failover sker inte: Relevant port övervakas förmodligen inte. Lägg till kritiska WAN-, Core- eller DMZ-portar som Monitored Ports.
• Active-Active fördelar inte som förväntat: Trafiktypen kanske inte lastbalanseras. Kontrollera anslutningstyp, protokoll och loggar på båda noderna; använd Active-Passive eller justera designen om nyttan är oklar.
• Loggar verkar saknas: Trafiken kan ha hanterats av den andra noden eller loggning kan vara avstängd. Kontrollera båda noderna och Log Viewer, aktivera loggning i regler och använd Central Reporting eller Syslog.
• Rapporter skiljer sig: Lokala rapporter är bundna till respektive nod. Jämför rapporter från båda enheterna eller använd Sophos Central Firewall Reporting.
• Licensproblem i Active-Active: Licenstyperna kanske inte stämmer. Kontrollera Licensing på båda brandväggarna och anpassa licenserna.
• Problem efter firmware-uppdatering: En nod är inte korrekt uppdaterad eller klustret är inte synkroniserat. Kontrollera HA-status, firmware-versioner och loggar; använd underhållsfönster och Sophos Support för produktionskluster.
• HA-Link via Flexi Port fungerar inte: Speed/Duplex eller Auto-Negotiation kan skilja sig. Kontrollera Interface Advanced settings på båda enheterna och konfigurera båda sidor lika eller använd fast port.

Hantering av fel på HA-Link

Var försiktig om Dedicated HA link fallerar. Brandväggarna kan inte längre se varandra. I värsta fall skickar båda ARP/GARP och försöker ta över Cluster MAC.

Säker process:

1. Stabilisera nätverkstillståndet.
2. Bestäm vilken enhet som ska förbli aktiv.
3. Stäng kontrollerat av den andra eller koppla bort den från produktionsnätet.
4. Reparera HA-Link-kabel, switchport, VLAN eller LAG.
5. Starta enheten igen.
6. Kontrollera HA-status.
7. Kontrollera loggar och roller.

Ytterligare CLI-kommandon

Utöver HA-statusfrågan under Validera klustret visar följande skrivskyddade kommando i Device Console:

show network interfaces

status för gränssnitt och länkar. UP förväntas för Dedicated HA link och anslutna Monitored Ports.

För att kontrollera återkommande länkavbrott går man till Shell via Device Management > Advanced Shell och ersätter PortE med det faktiska gränssnittsnamnet:

dmesg | grep PortE

Utdata filtrerar kärnmeddelanden för detta gränssnitt. Upprepade Link Up/Link Down-meddelanden tyder på problem med kabel, sändtagare, port eller förhandling. Kommandot ändrar inget; dmesg innehåller dock bara aktuell kärnbuffert och ersätter inte långsiktig logganalys.

Fullständig fysisk felsökning med ethtool, moduldata och kända specialfall beskrivs i Välja och kontrollera SFP och SFP+ för Sophos Firewall.

Spara alltid utdata och tidsstämplar före djupare ingrepp. Kommandona har kontrollerats mot aktuell Sophos-dokumentation men inte körts på kundens individuella hårdvara.

Checklista inför Go-live

• Valet av Active-Passive eller Active-Active är motiverat.
• Modeller, Flexi Ports, SFOS-build, LINCE-status, registrering och licenser är kontrollerade.
• Säkerhetskopia och återställningsväg finns.
• Dedicated HA link är ledig, stabil och om möjligt direktansluten.
• VLAN, LAG, switchportar och RSTP är konsekventa på båda sidor.
• Peer Admin-åtkomst till Auxiliary har testats.
• Endast stabila, kritiska gränssnitt är valda som Monitored Ports.
• Cluster ID, Initial Primary, Preferred primary och serienummer är dokumenterade.
• WebAdmin, CLI-status och relevanta loggar är kontrollerade.
• LAN, internet, servrar, VPN, DNAT/WAF, DNS och DHCP är funktionstestade.
• Failover och återgång är testade i underhållsfönster.
• Övervakning och processer för firmware, återställning och RMA är dokumenterade i driftinstruktionen.

FAQ

Officiella källor: Registrering och licenser · LINCE i HA-miljöer · RMA i ett Active-Passive-kluster · HA-FAQ