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

Avanets driftrekommendation: 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å. Detta är en designrekommendation, inte ett krav från Sophos.

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.
• När klustrets virtuella MAC används tar Auxiliary Firewall över samma virtuella MAC-adress vid failover.
• I detta fall behöver nätverksenheter 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 käll-IP-adressen för fördelningen: TCP-anslutningar från jämna källadresser hanteras vanligtvis av Primary, medan anslutningar från udda adresser går till Auxiliary. Vidarebefordrade eller översatta TCP-anslutningar fördelas, även över VLAN-gränssnitt. När Auxiliary har behandlat en anslutning skickar den paketen direkt till destinationen och inte tillbaka via Primary. Denna jämn-udda-metod är fast och kan inte ändras. 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. Denna ägarroll består oavsett om noden för närvarande är Active eller Passive.
• Preferred primary: Den enhet som ska återgå till rollen Primary efter failover när den åter är stabilt tillgänglig.

I Active-Passive visar WebAdmin på Auxiliary inte Live users, DHCP leases eller aktiva IPsec-anslutningar. Det är förväntat beteende och inget bevis på misslyckad synkronisering. Den för närvarande aktiva Primary är avgörande för dessa driftdata.

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

När HA-klustrets virtuella MAC används har produktionsgränssnitten virtuella MAC-adresser. 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. Alternativet för gränssnittets MAC som beskrivs nedan är en annan variant; anta inte samma övertagande av den virtuella MAC-adressen för det.

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 över Dedicated HA Link är VRRP-förfrågningar. SFOS 22 använder som standard 250 ms och 16 uteblivna heartbeats, vilket ger en heartbeat-timeout på 4 sekunder. SFOS 23 använder som standard 100 ms och 3 försök, vilket ger 300 ms; LAG-baserade HA-länkar kräver andra värden enligt beskrivningen nedan. Dessa timeouter garanterar ingen återställningstid för trafiken. För Monitored Ports räcker däremot ett enda portfel för att enheten ska betraktas som otillgänglig och failover utlösas.

Efter failover visar WebAdmin på den tidigare Auxiliary Firewall konfigurationen från Primary. Olika gränser gäller för aktiva sessioner:

När Initial Primary återvänder förblir den Auxiliary om Preferred primary inte är vald. Om den är Preferred primary synkroniserar SFOS först tjänsterna och växlar sedan tillbaka automatiskt. Enheten som fram till dess arbetade ensam startas om under processen. Planera därför denna failback i ett underhållsfönster även om klustret i allmänhet förblir tillgängligt under åtgärden.

Tjänster med stöd och begränsningar

Sophos HA stöder de flesta brandväggstjänster, men driftgränserna skiljer sig avsevärt:

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.

För konfiguration, säkerhetsgränser och tester, använd Konfigurera mDNS reflector. Tjänsteupptäckt ger inte åtkomst till applikationer; HA-stöd garanterar inte oavbrutna applikationssessioner. Detta mDNS-påstående gäller SFOS 23, inte SFOS 22.

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 Appliance-modell, exempelvis XGS 2100 med XGS 2100.
• Hårdvarurevision: Olika hårdvarurevisioner är möjliga med samma XGS Appliance-modell.
• XGS Appliance Wi-Fi-modeller: Stöds inte, exempelvis XGS 126w och XGS 136w.
• Flexi Port Module: Om expansionsmoduler används måste både antalet och modellen av Flexi Port-moduler 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.

Viktigt: Flexi Port-moduler kan inte bytas under drift. Stäng av båda brandväggarna kontrollerat, installera samma modulmodell i båda enheterna och starta om båda för att lägga till moduler. Konfigurera därefter de nya Flexi Ports endast på aktuell Primary under Network > Interfaces. SFOS synkroniserar denna portkonfiguration till Auxiliary. Ändra inte bara en nod medan klustret körs.

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 Appliance 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.

Om klustret använder den virtuella MAC-adress som SFOS skapar måste virtualiseringsplattformen acceptera MAC-ändringar. I VMware ESXi ska MAC Address Changes och Forged Transmits sättas till Accept på vSwitch eller port group; port groups måste ärva vSwitch-värdena eller konfigureras motsvarande. I Hyper-V aktiveras Enable MAC address spoofing på alla virtuella nätverkskort för båda brandväggarna, förutom kortet för Dedicated HA Link. Alternativt väljs Use host or hypervisor-assigned MAC address i SFOS 22 eller Use interface MAC address i SFOS 23; på virtuella enheter använder båda den MAC som hypervisorn tilldelat, så dessa plattformsändringar behövs inte. SFOS 23-alternativet använder även gränssnittets MAC på hårdvaruenheter i stället för klustrets virtuella MAC. Aktivering eller avaktivering uppdaterar gränssnittskonfigurationen och orsakar 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.

Gateway, Bridge och Discover/TAP

HA är tillgängligt i gateway- och bridge-läge. Discover- eller TAP-läge stöder endast Active-Passive. Om minst en nod körs i discover-läge kan inget Active-Active-kluster skapas. Ett aktivt TAP-gränssnitt blockerar även Active-Passive-konfigurationen. Inaktivera TAP-gränssnittet via CLI på båda brandväggarna, etablera HA och aktivera sedan TAP separat på varje nod. TAP förblir aktivt även på passiv Auxiliary.

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, men licensen upphör när enheten når End of Life. På cloud-, virtuella och programvaruenheter löper Base Firewall-licensen inte ut, men den måste finnas för HA.
• 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 Fusion (tidigare 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: Advance Hardware Replacement kräver Enhanced Plus Support på Primary i ett Active-Passive-hårdvarukluster. I Active-Active kräver varje enhet Enhanced Support eller Enhanced Plus Support.

Hantera HA-paret i Sophos Fusion

Ett befintligt HA-par hanteras i Sophos Fusion som ett par, inte som två fristående brandväggar. Båda noderna behöver samma firmwareversion och, för Central Management, fungerande IPv4-internetåtkomst och rätt abonnemang. Enbart registrering och licenssynkronisering aktiverar inte hanteringen.

När två brandväggar som redan hanteras separat i Sophos Fusion ska bilda ett HA-par rekommenderar Sophos att båda först avregistreras. Etablera HA lokalt, registrera det färdiga paret för Central Management igen och flytta det vid behov till en annan Central-grupp.

Öppna System > Sophos Central på aktuell Primary och välj Register both HA devices. Aktivera sedan Central Management och öppna Approval Pending för Primary under My Products > Firewall Management > Firewalls i Sophos Fusion och bekräfta accept-services. Efter några minuter ska paret visas en gång med HA-ikonen; ändringar från Sophos Fusion gäller då båda brandväggarna.

Statusen i Central ersätter inte lokal validering. Kontrollera efter registreringen HA-roller, synkronisering, licensstatus och en ofarlig konfigurationsjämförelse lokalt. Om två fristående poster visas eller Approval Pending kvarstår ska ingen brandvägg avregistreras i förebyggande syfte. Jämför först serienummer, Central-tenant, IPv4-väg och lokal HA-status.

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.

Licens på fel brandvägg – endast Active-Passive: Om Active-Passive-abonnemangen av misstag har tilldelats Auxiliary i stället för den licensbärande Initial Primary räcker inte synkronisering. Inaktivera HA planerat på aktuell Primary, överför abonnemangen från Auxiliary till Primary i Sophos Fusion och konfigurera därefter Active-Passive-klustret på nytt. Licensöverföringar är också relevanta vid RMA eller modellbyte, men kräver rätt procedur för det specifika fallet. Eftersom HA-modellerna måste vara identiska måste båda enheterna bytas vid ett modellbyte. I Active-Active måste även Auxiliary ha egna licenser. Detta är inte ett fel och ska inte korrigeras med denna överföring. Använd inte denna Active-Passive-procedur för Active-Active-RMA utan tillämpliga Sophos-instruktioner.

Utgångna eller osynkroniserade Active-Active-licenser kan stoppa lastbalanseringen och inaktivera HA. För hårdvara och Virtual/Software beskriver Sophos stoppets början motsägelsefullt: sammanfattningen anger slutet av tre dagar, medan detaljpunkterna anger de första tre dagarna och därefter HA-inaktivering. Den exakta början är inte klarlagd; detta är ingen garanterad frist på tre dagar. Korrigera licensproblem snarast och kom vid behov överens med Sophos Support om en säker driftplan för den installerade builden. Vid första konfigurationen aktiveras inte Active-Active med licenser som inte stämmer.

I Active-Passive ska Primarys licenser synkroniseras. Den licensbärande Initial Primary måste synkronisera dem 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.

I Active-Active, på hårdvara och Virtual/Software, ska båda enheternas licenser synkroniseras individuellt med Sophos Fusion och resultatet kontrolleras på både Primary och Auxiliary. Matchande licenstyper och innehav av licenser ersätter inte detta steg. På hårdvara förblir Base Firewall och Enhanced Support aktiva vid de beskrivna licensproblemen; på Virtual/Software inaktiverar en inaktiverad Base Firewall-licens HA och gör övriga licenser inaktiva. Använd inte den oklara uppgiften om tre dagar som synkroniseringsintervall.

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 framgångsrikt; i Active-Active dokumenteras status och tid separat för båda noderna
• 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.

I Active-Passive kan produktionsgränssnitt använda DHCP, DHCP Prefix Delegation eller PPPoE, men Dedicated HA Link och båda administrationsportarna kräver fortfarande statiska adresser. I Active-Active måste alla gränssnitt ha statiska adresser.

Konfigurera breakout-gränssnitt på Primary. Starta först om Primary för att tillämpa ändringen och starta sedan om Auxiliary. Om Primary saknar motsvarande breakout-konfiguration tar synkroniseringen bort en breakout-konfiguration som endast finns på Auxiliary.

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 kan inte återanvändas för HSRP eftersom HSRP-hello-meddelanden inte passerar Dedicated HA Link. 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. Båda noderna använder samma administrationsnät. SFOS synkroniserar dock den vanliga gränssnittskonfigurationen, inklusive PortMGMT-IP, från Primary till Auxiliary; denna gränssnitts-IP kan därför inte skilja sig per nod. Den separata inställningen Peer Administration ger Auxiliary en ytterligare, avvikande administrations-IP i samma subnät. QuickHA använder automatiskt gränssnittet för aktuell WebAdmin-session. Efter HA-konfigurationen nås Auxiliary endast via denna Peer Admin-adress från motsvarande subnät.

Standardadressen för vanliga portar är 172.16.16.16; den särskilda PortMGMT på större enheter använder 10.0.1.1. Primary är åtkomlig från varje zon där HTTPS tillåts under Administration > Device access. För WebAdmin på Auxiliary måste administrationsenheten finnas i samma subnät som dess administrationsport.

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.

I SFOS 23 kräver en Dedicated HA link med LAG eller VLAN över LAG Keepalive request interval × Keepalive attempts ≥ 2500 ms. SFOS 23-installationens standardvärde 100 ms × 3 = 300 ms uppfyller inte detta LAG-krav och får inte användas oförändrat här. Ett tillåtet exempel är 250 ms × 10 försök = 2500 ms, inte ett universellt standardvärde. QuickHA skapar en HA redundant link som LAG när fler än ett obundet fysiskt gränssnitt väljs, så kravet gäller även denna topologi. Kontrollera den faktiska länkkonfigurationen. Anta inte att QuickHA automatiskt förhandlar fram lämpliga värden; kontrollera de konfigurerade värdena innan du förlitar dig på klustret.

Höghastighetsportar: För 25, 50 och 100 GbE-portar på XGS 7500/8500 Series väljs samma Link mode med matchande hastighet och duplex på båda sidor under Network > Interfaces > Advanced settings. Använd sedan Show recommended settings > Load recommended configuration för negotiation och Forward Error Correction (FEC). Om rekommendationerna är tomma, stäng av Auto-negotiation för Media Type och FEC. För andra portar används Automatic eller identiska speed/duplex-värden, och MTU samt MSS lämnas på standardvärdena. När QuickHA väljer ett obundet gränssnitt återställer SFOS dess Advanced settings; kontrollera dem igen efter att HA har etablerats.

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.
• Geografiskt separerade HA-noder är endast lämpliga över ett Layer 2-nät med låg latens i samma broadcast-domän. Dedicated HA Link ligger kvar i samma IP-subnät; hög latens eller paketförlust gör designen olämplig.
• 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.

Förstå och aktivera LINCE-läge på Sophos Firewall förklarar varför läget inte automatiskt certifierar den installerade SFOS-builden och vilka SSH-algoritmer som måste kontrolleras före aktiveringen.

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.

Förberedda QuickHA-enheter fortsätter att söka efter sin peer tills de hittar den. De kan därför konfigureras i förväg och anslutas senare på målplatsen. När en enhet har hittat peeren och HA håller på att upprättas kan denna discovery-process inte längre stoppas. Gränssnittsval, Passphrase och avsedd peer måste därför vara korrekta innan båda HA-länkarna är nåbara samtidigt.

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 Fusion-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.

Fysiska gränssnitt, LAG och obundna gränssnitt med ett konfigurerat VLAN kan väljas. Ett obundet gränssnitt utan VLAN kan inte väljas som Monitored Port. Monitored Ports kräver statiska IP-adresser i båda HA-lägena.

SFOS 23 tillåter högst 24 Monitored ports. Håll urvalet åtskilt från Dedicated HA link och ta endast med produktionslänkar som verkligen behövs.

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?
• Har båda nodernas licenser synkroniserats individuellt med lyckat resultat, med status och tid dokumenterade separat?
• 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.

Tillåt före konfigurationen SSH och Ping/Ping6 för DMZ-zonen på båda enheterna under Administration > Device access. Interactive mode väljer först automatiskt det första DMZ-gränssnittet som Dedicated HA link. Om gränssnittet inte är avsett för HA eller har produktionsberoenden väljs ett ledigt fysiskt, VLAN- eller förberett LAG-gränssnitt innan konfigurationen sparas.

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; SFOS 23 tillåter högst 24.
6. Ange administrationsgränssnitt och en egen IP-adress för FW02 under Peer administration settings.
7. Välj vid behov Use host or hypervisor-assigned MAC address för virtuella enheter i SFOS 22, eller Use interface MAC address i SFOS 23. SFOS 23-alternativet använder hypervisorns MAC på virtuella enheter och gränssnittets MAC på hårdvara i stället för klustrets virtuella MAC. Aktivering eller avaktivering orsakar driftavbrott.
8. Ange Preferred primary och välj Initiate HA.

Ändra Keepalive-värden efter uppbyggnaden endast med dokumenterat skäl. SFOS 22 tillåter intervall på 250–500 ms och 16–24 försök; standardvärdena 250 ms och 16 försök ger 4 sekunders timeout. SFOS 23 tillåter 100–500 ms och 3–24 försök; standardvärdena 100 ms och 3 försök ger 300 ms. För SFOS 23 Dedicated HA-länkar med LAG eller VLAN över LAG måste produkten vara minst 2500 ms: 250 ms × 10 försök är ett tillåtet exempel, inte det allmänna standardvärdet. Kontrollera även redundanta LAG som QuickHA skapat. Dessa värden kan inte ändras när enheterna har status Standalone eller Faulty. Efter timeouten genomför den nya Primary interna kontroller innan den börjar hantera trafik. Ingen av dessa timeouter garanterar en återställningstid för trafiken.

I de avancerade HA-inställningarna för SFOS 23 är Monitor hardware components valfritt och lägger till en failover-utlösare när ett problem med en lagringsenhet upptäcks, utöver heartbeat-fel och fel på övervakade gränssnitt. Anta inte att det är aktiverat som standard eller upptäcker alla hårdvarufel.

API-anmärkning för SFOS 23: API-parametertabellen anger HardwareMonitor som en valfri skalär parameter (SCALAR, Mandatory: No), med värdena Enable och Disable och det dokumenterade API-standardvärdet Enable. Det värdet i dokumentationen bevisar varken den faktiska GUI-inställningen eller enhetens tillstånd under drift. Kontrollera inställningen på den installerade enheten; den ovan beskrivna begränsningen till lagringsenheter gäller fortfarande.

XML-exemplet för SFOS 23-API:t innehåller fortfarande Number(250-500) och Number(16-24). Dessa platshållare stämmer inte med tabellens intervall, 100–500 ms och 3–24 försök, och får inte kopieras som fullständiga gränser. Det bevisar varken att produkten avvisar de lägre värdena eller att API-beteendet har testats.

Ansluta en ny virtuell Auxiliary som HA spare

För en ny virtuell Auxiliary i Active-Passive kan Setup Assistant använda Connect as HA spare. Active-Active eller två befintliga Virtual/Software-brandväggar kräver fortfarande QuickHA eller Interactive mode på båda enheterna.

1. Tillåt SSH för DMZ på befintlig Primary under Administration > Device access och förbered Active-Passive i Interactive mode. Dokumentera Dedicated HA Link, peer-IP, Peer Administration och HA-passphrase. Primary kan visa Standalone tills den nya Auxiliary ansluter.
2. Installera den nya virtuella brandväggen med exakt samma SFOS-build, starta Setup Assistant och ange ett nytt administratörslösenord.
3. Välj Connect as HA spare och ange serienumret för befintlig Primary, samma HA-passphrase, samma Dedicated-HA-Link-gränssnitt och en ledig IP-adress med samma subnätmask.
4. Välj Apply, Continue och Finish. SFOS skapar Auxiliary, tilldelar ett serienummer som börjar med HAAUX och konfigurerar Dedicated HA Link samt administrationsport automatiskt.
5. Uppdatera WebAdmin på Auxiliary efter några minuter och logga in igen. Kontrollera sedan roller, synkronisering, Peer Admin, Monitored Ports och failover på Primary.

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

Kontrollera driftparametrar i SFOS 22

SFOS 22 publicerar två ytterligare HA-kontroller. Läs båda innan någon ändring görs:

system ha auxiliary_system_traffic_through_dedicated_link show
system ha load-balancing show

Den första kontrollen bestämmer vägen för systemtrafik som Auxiliary Firewall själv skickar. Som standard går all denna trafik över Dedicated HA Link. Förutom all finns none och only_dynamic_interface. Sophos definierar inte närmare vilka flöden som räknas som ett dynamiskt interface i det sista läget. Använd därför alternativet endast för ett användningsfall som har bekräftats för den installerade builden, inte som en generell routingkorrigering.

Den andra kontrollen slår på eller av fördelningen av kvalificerad trafik mellan brandväggarna. Den ersätter inte valet av HA-läge och gör inte de tjänster och tunnlar som undantas ovan lämpliga för load balancing. Utför ändringar en i taget i ett underhållsfönster och spara båda show-utdata först:

system ha auxiliary_system_traffic_through_dedicated_link [all|none|only_dynamic_interface]
system ha load-balancing [on|off]

Kontrollera därefter roller, synkronisering, Dedicated HA Link, nya sessioner, nodlokala loggar och systemanslutningar som Auxiliary själv initierar. Återställ det tidigare avlästa värdet vid rollback. Sophos dokumenterar all som standardvärde endast för den första kontrollen; för load balancing ska inget standardvärde antas.

Vilken enhet som är licensbärande Initial Primary kontrolleras under System services > High availability. Sophos dokumenterar även följande officiella CLI-kontroll i Advanced Shell:

nvram get "#li.master"

YES identifierar Initial Primary som innehar klusterlicenserna, medan NO identifierar enheten som är konfigurerad som Auxiliary. Kommandot är skrivskyddat. HA-vyn är smidigare för dagliga kontroller, men shell-utdata är också officiellt dokumenterad.

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 Fusion, 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.

Auxiliary skickar rapportmejl endast för rapporter som faktiskt innehåller data på den noden, exempelvis e-postaktivitet eller Pattern Updates. Rapporter utan data, såsom Security Dashboard eller Security Audit, skickas inte. Ett uteblivet mejl för dessa rapporttyper är därför inte i sig ett bevis på ett fel.

För HA-händelser öppnas Log viewer > System separat på varje nod och den berörda perioden filtreras fram. För detaljerad analys öppnas Diagnostics > Tools > Troubleshooting logs > Select files på båda enheterna, minst csc.log väljs och varje paket sparas separat med Download. Först jämförelsen mellan båda noderna visar hela klusterförloppet.

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

Manuell synkronisering och tvingat rollbyte

Automatisk synkronisering är normal drift. Använd Sync auxiliary device på Primary eller Auxiliary endast för att åtgärda ett bekräftat synkroniseringsproblem. Auxiliary startar om, utför en fullständig synkronisering av databasen och tillhörande filer och förblir Auxiliary. Loggar och rapporter förblir lokala på respektive nod. Brandväggen bryter alla maskerade anslutningar under processen, så åtgärden ska planeras i ett underhållsfönster.

I Active-Passive kan Auxiliary tvingas ta över med Switch to passive device på aktuell Primary eller Switch to active device på aktuell Auxiliary. Aktuell Primary startar om. Det är ett planerat rollbyte med risk för sessioner, inte en ofarlig omkopplare.

Inaktivera HA kontrollerat

Inaktivera om möjligt HA på aktuell Primary under System services > High availability > Disable HA. Vilken nod som används avgör resultatet:

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.

En firmware-rollback av HA-paret följer samma process och kräver inte att HA först inaktiveras.

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

Skapa säkerhetskopior regelbundet och före varje större ändring. När LINCE är aktiverat måste säkerhetskopian och målklustret ha samma LINCE-status. Det finns tre återställningsscenarier:

Varning för en säkerhetskopia utan HA: Sophos beskrivningar för SFOS 22 och 23 motsäger sig själva om Auxiliarys tillstånd efter denna återställning: brödtexten säger att den tidigare konfigurationen behålls, medan sammanfattningen anger en fabriksåterställning med undantag för Peer Admin Port och Dedicated HA Link. Varken fullständigt bevarande eller fabriksåterställning är därför fastställt beteende. Förlita inte driften på att Auxiliarys konfiguration bevaras. Spara först konfigurationerna externt, dokumentera administrations-IP-adresser och inloggningsuppgifter och planera driftavbrott och återuppbyggnad av HA. Klargör förfarandet för den installerade SFOS-versionens build med Sophos Support innan driften blir beroende av Auxiliarys osäkra tillstånd.

Om Primary var registrerad som Sophos ZTNA-gateway ska den läggas till som gateway i Sophos ZTNA igen efter återställning till HA-klustret.

Ominstallera HA-noder i Active-Passive

En ominstallation avbryter driften och enligt Sophos gäller dessa processer endast Active-Passive. Kör först system diagnostics show version-info i Device Console på båda noderna, dokumentera firmware inklusive build och Initial Primary och spara en aktuell säkerhetskopia externt.

Om klustret använder Sophos Fusion 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 Fusion 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 Fusion.
2. Installera samma firmware-build på ersättningsenheten, registrera den i Sophos Fusion 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 Fusion 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 Appliance-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 efter en uppdatering: på 1U-modellerna XGS 2100, XGS 2300, XGS 3100, XGS 3300, XGS 4300 och XGS 4500 kan HA inte etableras när en Flexi Port används som Dedicated HA link. Efter att den första enheten har uppdaterats och startats om är dess Interface speed inte längre inställd på Auto negotiation, medan den andra enheten fortfarande använder Auto negotiation.

  Före ändringen: dokumentera HA-roller och portinställningar på båda enheterna, säkerställ en säkerhetskopia och separat administrationsåtkomst och använd ett underhållsfönster. Vid Split-Brain ska först nedanstående process för HA-Link-fel följas: bestäm vilken nod som ska förbli aktiv och koppla bort den andra från produktionsnätet eller stäng av den kontrollerat. Starta inte om båda noderna utan samordning.

  1. Öppna Network > Interfaces på båda enheterna.
  2. Välj det berörda Flexi Port-gränssnittet och öppna Advanced settings.
  3. Ställ in Interface speed på Auto negotiation.

  Kontrollera därefter länkstatus, HA-roller, synkronisering och produktionstrafik. Om problemet kvarstår, spara inställningar och loggar från båda noderna och kontakta Sophos Support. Återställ de dokumenterade tidigare värdena endast som en kontrollerad ändring med säkerställd administrationsåtkomst; det kan få HA-Link-felet att återkomma. Alternativt kan en inbyggd port planeras som Dedicated HA link, inte ett fast hastighetsvärde. Ändringen har kontrollerats mot dokumentationen men inte testats på en enhet.

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