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 du börjar ska du kontrollera att båda enheterna, deras firmware-buildar, licenserna, kabeldragningen och administrationsåtkomsten uppfyller HA-kraven.

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 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: Lämpliga TCP-anslutningar från jämna käll-IP-adresser hanteras av Primary, medan anslutningar från udda adresser går till Auxiliary. Vidarebefordrad TCP-trafik och översatta TCP-anslutningar fördelas, inklusive SNAT och Virtual Host-trafik, ä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. Stödet för Layer 7 varierar: Enligt Sophos stöder DPI Engine, transparenta proxyer, direkta proxyer och Parent Proxies samt SMTP-proxytrafik och HTTPS lastbalansering. Skannad FTP och H.323 gör det inte. Även icke-TCP-trafik som UDP, ICMP, multicast och broadcast, SD-RED samt tunnlad TCP- och icke-TCP-trafik inklusive VPN är undantagna. Externa lastbalanserare stöds inte för HA.

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 påvisbar nytta av fördelningen för den relevanta trafiken. 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 tilldelar SFOS virtuella MAC-adresser till de fysiska gränssnitten, med undantag för Dedicated HA Link och administrationsportarna. Dedicated HA Link använder sin egen fysiska MAC-adress. Endast Primary besvarar ARP-förfrågningar för klustret. Vid failover tar Auxiliary över den virtuella MAC-adressen för respektive produktionsgränssnitt. 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 viktigt eftersom det 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. I Active-Active utbyter båda enheterna status och detaljer om aktiva sessioner med den andra noden; konfigurationssynkroniseringen sker däremot fortfarande från Primary till Auxiliary.
• Secure Storage Master Key och inloggningsuppgifter för WebAdmin synkroniseras.
• Dedicated HA link och administrationsportar är uttryckligen undantagna från synkronisering enligt Sophos officiella beskrivning av HA-lägen och roller. Motstridiga instruktioner om administrationsadresser beskrivs under Nätverkskrav.
• Loggar och rapporter synkroniseras inte mellan enheterna.

Beteende vid failover

I Active-Passive tar Auxiliary över all trafik om Primary fallerar. I Active-Active kan däremot ett fel på någon av de två aktiva enheterna utlösa ett övertagande av den friska noden. Om Auxiliary fallerar hanterar Primary all trafik ensam; det innebär inte nödvändigtvis ett rollbyte. Om en nod blir otillgänglig arbetar den kvarvarande enheten som Standalone. Denna status är därför inte i sig ett bevis på att HA-Link har fallerat på båda sidor; kontrollera båda nodernas roller och nåbarhet innan driftinstruktionen för Split-Brain tillämpas.

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 nod startar i Failsafe-läge dokumenteras först dess roll och den andra nodens tillstånd. Kontrollera Sophos Firewall i Failsafe-läge beskriver det säkra diagnosförfarandet och förklarar varför båda noderna 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.

Motstridiga heartbeat-uppgifter för SFOS 23: Den allmänna failover-beskrivningen anger fortfarande 250 ms och 16 försök, medan de detaljerade konfigurationsanvisningarna för SFOS 23 anger 100 ms och 3 försök. De standardvärden för SFOS 23 som anges här kommer från de detaljerade konfigurationsanvisningarna, inte från en mätning på enheten. Dokumentera de faktiskt konfigurerade värdena och HA-Link-topologin på båda noderna före en ändring under System services > High availability. Varken den äldre uppgiften eller det kortare standardvärdet i konfigurationsanvisningarna är skäl att ändra ett befintligt kluster utan kontroll; om värdena är oklara eller inte uppfyller LAG-kravet ska planeringen klargöras med Sophos Support.

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 i klustret om Preferred primary inte är vald. Om den är angiven som 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. Denna failback ska därför planeras i ett underhållsfönster. De beskrivna rollbytena och omstarterna garanterar inte oavbruten hantering av befintliga anslutningar.

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. Exempel på virtuella plattformar är Microsoft Hyper-V, VMware och Nutanix Prism; programvaruenheter körs på egen hårdvara. Att en plattform nämns ersätter inte kontrollen av följande HA-krav.

• Plattform: Samma enhetstyp och SFOS-plattform.
• Hypervisor: Samma Hypervisor-typ.
• Resurser: Identiskt tilldelade hårdvaruresurser, inklusive samma antal CPU-kärnor, samt 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 en egen Base Firewall-licens och matchande ö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 HA-par kan anslutas till switchar i accesslagret, inklusive Sophos Switches. Sophos Fusion, tidigare Sophos Central, möjliggör central hantering av brandväggarna och Sophos-switcharna. Detta ersätter inte en redundant switchdesign: en gemensam switch kan fortfarande påverka båda noderna. Den äldre översikten för SFOS 23 använder fortfarande namnet Sophos Central; det innebär inte en annan HA-arkitektur.

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. Dokumentera före varje ändring källserienumret för den felaktigt licensierade Auxiliary och det avsedda målserienumret för Initial Primary separat från de aktuella HA-rollerna och stäm av uppgifterna i SFOS och Sophos Fusion. Denna förkortade korrigeringsprocedur gäller endast om aktuell Primary och Initial Primary är samma fysiska enhet. Om de är olika enheter eller tilldelningen är oklar, stoppa före inaktivering av HA eller licensöverföring och klargör rätt procedur med hjälp av Sophos-anvisningarna eller Sophos Support; improvisera inte ett rollbyte tillbaka. Först när tilldelningen är entydig ska HA inaktiveras planerat på aktuell Primary, abonnemangen överföras i Sophos Fusion från det dokumenterade källserienumret till det dokumenterade målserienumret för Initial Primary och Active-Passive-klustret därefter konfigureras 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 var 90:e dag. 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, DHCP Prefix Delegation eller PPPoE. PPPoE-anslutningen 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. Den dokumenterade PPPoE-begränsningen belägger inget generellt undantag från sessionsövertagning för DHCP-gränssnitt. Adresstilldelning och DHCP-protokolltrafik är skilda från bevarande av vidarebefordrade TCP-sessioner. Tillämpa protokoll- och tjänstegränserna ovan; detta innebär inte heller någon generell garanti för sessionsövertagning på DHCP-gränssnitt.

Breakout-gränssnitt konfigureras på Primary. Vid en ny breakout-konfiguration ska först Primary startas om för att tillämpa ändringen och därefter Auxiliary. Om motsvarande breakout-konfiguration redan finns på Primary ska endast Auxiliary startas om efter synkroniseringen. Om Primary saknar motsvarande breakout-konfiguration tar synkroniseringen bort en breakout-konfiguration som endast finns på Auxiliary. De enskilda fallen förklaras i Konfigurera breakout-gränssnitt.

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. QuickHA använder automatiskt gränssnittet för aktuell WebAdmin-session. Efter HA-konfigurationen dokumenteras åtkomst till Auxiliary via Peer Admin-adressen från samma subnät som administrationsporten.

Motstridiga instruktioner om administrationsadresser: Sophos officiella beskrivning av HA-lägen och roller undantar uttryckligen Dedicated HA Link och administrationsportarna från synkronisering. De HA-specifika gränssnittskraven anger att båda administrationsportarna ska ha olika statiska IP-adresser i samma subnät. Startguiden för management-porten förbjuder däremot olika PortMGMT-IP-adresser i HA med hänvisning till att konfigurationen synkroniseras. Dessa officiella instruktioner motsäger varandra. En gemensam PortMGMT-IP med en ytterligare peer-IP är inte en fastställd lösning på motsägelsen.

Före HA-konfiguration eller ändringar av administrationsadresser ska aktuella Primary-/Auxiliary-roller (eller avsedda roller för fristående enheter), exakt installerad SFOS-build, valt administrationsgränssnitt och aktuella IP-adresser dokumenteras. Säkra en aktuell säkerhetskopia och en separat administrativ åtkomstväg via konsol eller lokal anslutning. Verifiera vilket adressbeteende som gäller för den installerade builden med hjälp av tillämpliga anvisningar eller Sophos Support. Om motsägelsen inte kan klarläggas, stoppa före Initiate HA eller ändringar av administrationsadresser.

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 ska samma Link mode med matchande hastighet och duplex väljas på båda sidor under Network > Interfaces > Advanced settings och sparas med Save. Öppna därefter gränssnittet för redigering igen, använd Show recommended settings > Load recommended configuration för förhandling och Forward Error Correction (FEC) och spara igen med Save. Om rekommendationerna fortfarande är tomma efter den första sparningen och efter att gränssnittet öppnats igen ska Auto-negotiation för Media Type och FEC inaktiveras och ändringen sparas. För andra portar används Automatic eller identiska hastighets- och duplexvä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 dessa värden 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:

• Klargjort adressbeteende för administrationsportarna: Följ förkontrollen under Nätverkskrav. Dokumentera aktuella Primary-/Auxiliary-roller (eller avsedda roller för fristående enheter), exakt SFOS-build, valt administrationsgränssnitt och aktuella IP-adresser; säkra säkerhetskopia och separat konsol-/lokal administrationsåtkomst. Verifiera tillämpligt beteende för builden eller fråga Sophos Support. Om källkonflikten kvarstår, stoppa före Initiate HA eller ändringar av administrationsadresser.
• 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. Innan en enhet byts i ett fortfarande fungerande HA-par måste HA därför inaktiveras och därefter konfigureras på nytt med ersättningsenheten. Det särskilda utgångsläget efter RMA och de avvikande beskrivningarna av ominstallation förklaras i respektive avsnitt längre ned.

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.

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.

Nodnamn i QuickHA: I SFOS 22 är namngivning valfri. För SFOS 23 kräver de detaljerade anvisningarna ett nodnamn, medan exempelanvisningarna fortfarande anger att det är valfritt. Följande checklista tilldelar därför båda enheterna olika, tydligt identifierbara namn. Detta är en försiktig rekommendation och inget bevis på att GUI:t avvisar ett tomt namnfält.

Konfigurera HA

Förkontrollen för administrationsadresser under Nätverkskrav och checklistan före Initiate HA gäller samtliga konfigurationsvägar nedan, även Connect as HA spare. Fortsätt inte om källkonflikten för den installerade builden är olöst.

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 ett unikt nodnamn, 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 ett annat nodnamn än på Primary, 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. Urvalsfältet heter Select ports to be monitored i SFOS 22 och Monitored interfaces i de detaljerade anvisningarna för SFOS 23. 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.

HA fungerar även utan valda Monitored Ports. Då utlöser ett fel på en produktionsport inte i sig failover; heartbeat-fel, enhetsfel eller strömavbrott kan fortfarande utlösa ett rollbyte. Varje port som faktiskt väljs måste vara ansluten på båda noderna. Övervakning av portstatus upptäcker inte alla fel hos en uppströmsleverantör.

Avancerade HA-inställningar som Monitored interfaces, Peer administration, Preferred primary och Keepalive-värden ändras på aktuell Primary efter att QuickHA har etablerats. Kontrollera först säkerhetskopia, underhållsfönster och säkerställd administrationsåtkomst; MAC-ändringen som beskrivs ovan orsakar driftavbrott. Före ändringar av Peer administration eller administrationsadresser ska även förkontrollen för adresskonflikten under Nätverkskrav vara genomförd; stoppa om beteendet för den installerade builden är oklart. För en LAG-baserad HA-Link ska Keepalive-kravet följas, och värden får inte ändras i status Standalone eller Faulty. När önskat urval har gjorts, skrolla tillbaka till sidans början och välj Initiate HA. Då synkroniserar Primary ändringarna till Auxiliary. Kontrollera därefter HA-roller, status, synkronisering och de ändrade värdena på båda noderna; vid avvikelser ska först HA-Link och loggar från båda enheterna jämföras. Detta avslutande steg gäller även följande Active-Active-variant och ska skiljas från enheternas första anslutning till klustret.

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 matchande 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 samt den statiska HA-Link-IP-adressen för Auxiliary. Fältet heter Dedicated peer HA link IPv4 address i SFOS 22 och Peer IPv4 address of dedicated HA link i de detaljerade anvisningarna för SFOS 23. Båda HA-Link-adresserna måste ligga i samma subnät. Detta är inte administrations-IP-adressen under Peer administration settings; dess förhållande till gränssnittets IP-adress ska klargöras i förväg enligt ovan.
5. Välj kritiska Monitored ports; SFOS 23 tillåter högst 24.
6. Ange administrationsgränssnitt och IP-adress för FW02 under Peer administration settings först när förkontrollen under Nätverkskrav har klarlagt adressbeteendet för den installerade builden. Stoppa före adressändringar eller Initiate HA om källkonflikten kvarstår.
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.

API-avvikelse i SFOS 22: Beskrivningen av Keepalive attempts anger 8–16 försök, medan den detaljerade parameterbegränsningen och XML-exemplet anger 16–24. Intervallet följer den detaljerade begränsningen; 8–16 är inte ett andra bekräftat intervall. Dokumentera den installerade SFOS-builden och de aktuella Keepalive-värdena på båda noderna före ändringar. Om det fortfarande är oklart vilka gränser som gäller ska detta klargöras med Sophos Support före en ändring; LAG-kraven ska fortfarande följas.

API-förkontroll för SFOS 22 och 23: Parametertabellerna dokumenterar ClusterId som ett valfritt heltal inom 0–63 med standardvärdet 0 och NodeName som en obligatorisk teckensträng med 1–30 tecken. Även med det dokumenterade standardvärdet måste varje kluster i det gemensamma Layer 2-nätet använda ett unikt Cluster ID för att undvika konflikter mellan virtuella MAC-adresser. Dessa API-metadata ändrar inte GUI-anvisningarna ovan om valfri respektive obligatorisk namngivning och belägger ingen GUI-validering. Tabellen använder ClusterId, medan XML-exemplet använder ClusterID; mappningen måste klarläggas innan en API-payload byggs.

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. Denna procedur är ett alternativ till uppbyggnaden ovan med Auxiliary först och två redan befintliga enheter: den nya spare-VM:n konfigureras inte som Auxiliary i förväg. Slutför förkontrollen ovan för administrationsadresser före Initiate HA och stoppa om motsägelsen inte har klarlagts. Automatisk konfiguration av administrationsporten löser inte de motstridiga adresskraven. 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 välj Primary (active-passive) samt Interactive mode under System services > High availability. I SFOS 23 ska du ange ett Cluster ID och ett nodnamn före Initiate HA; anvisningarna för SFOS 22 beskriver inmatning av Cluster ID och ändring av nodnamnet som valfria. Om flera HA-kluster finns i samma Layer 2-nät måste varje kluster använda ett annat Cluster ID för att förhindra konflikter mellan virtuella MAC-adresser. Dokumentera Dedicated HA Link, dess egen IP-adress och subnätmask, avsedd peer-IP, Peer Administration och den HA-passphrase som används på Primary på ett säkert sätt. Välj därefter Initiate HA; skrolla i SFOS 23 tillbaka till sidans början för att göra detta. Sophos spare-anvisningar dokumenterar i detta skede, innan den nya VM:n ansluter, meddelandet HA could not be enabled och tillfälligt statusen Standalone. Inget av dessa är i sig ett bevis på ett misslyckat färdigt kluster under denna uppbyggnadsfas.
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 som tidigare användes på Primary och dokumenterades säkert samt samma Dedicated-HA-Link-gränssnitt. Använd för den nya spare-enheten en egen, ledig IP-adress som skiljer sig från Primarys adress och ligger i subnätet för befintlig Primarys Dedicated HA Link, med identisk subnätmask; adressen måste motsvara den peer-IP som förbereddes där. Förutsätt inte att det finns en passphrase från en Auxiliary som antas vara redan konfigurerad.
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 internetåtkomst från en LAN-klient.
• 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.

I Active-Active ger käll-IP-adressen en första indikation på vilken nod som förväntas logga trafiken: För lämplig TCP-trafik hör jämna adresser till Primary och udda till Auxiliary. Detta gäller inte generellt för de trafiktyper som undantas ovan och ersätter inte en jämförelse mellan båda enheterna, särskilt efter ett rollbyte.

För HA-händelser öppnas Log viewer > System separat på varje nod. Välj lämpligt filter och värde för den berörda perioden via Add filter och tillämpa filtret med knappen Add filter. För detaljerad analys öppnas Diagnostics > Tools > Troubleshooting logs > Select files på båda enheterna. Välj csc.log för den centrala tjänst som hanterar de övriga tjänsterna. Välj även de HA-filer som beskrivs nedan under Viktiga loggar och diagnosplatser och spara varje paket separat med Download. För att rekonstruera klusterförloppet ska loggmaterialet från båda noderna jämföras, med särskild uppmärksamhet på tidsluckor och roterade 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

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

Sophos HA-FAQ för SFOS 22 och 23 anger ett generellt krav: inaktivera HA före ominstallation, före byte av en nod i HA-paret och före licensöverföring mellan noderna. Den passphrase som används en gång för SSH-tunneln raderas när tunneln har upprättats; för en ny enhet måste HA därför inaktiveras och konfigureras på nytt. Detta krav ersätter inte planering för det specifika fallet: de följande detaljerade anvisningarna för ominstallation innehåller en avvikelse i dokumentationen, och RMA-procedurerna förutsätter att en frisk nod redan är i tillståndet Standalone HA. Planera först säkerhetskopiering, säkerställd administrationsåtkomst, underhållsfönster och återuppbyggnad; följ vid licenskorrigering i Active-Passive dessutom villkoret för serienummer och roller som beskrivs ovan.

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

Åtkomst via Fusion från SFOS 22 MR1: Sophos Known Issues, NC-186855, beskriver ett undantag från den allmänna effekten ovan: Om HA inaktiveras i brandväggsgränssnittet som öppnats via Sophos Fusion/Central med FRP-SSO kan Auxiliary bli kvar som Standalone med HA aktiverat, medan HA redan är avstängt på Primary. Detta medför risk för split brain. Kontrollera HA-status separat på båda enheterna efter åtgärden. Om tillståndet är motsägelsefullt ska den planerade återuppbyggnaden pausas och återställningen samordnas med Sophos Support innan enheterna används som ett par igen. En lyckad dialog på Primary räcker inte som kontroll. Den 24 oktober 2026 anger posten ingen korrigerad version.

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 avbrytas tillfälligt eller kräva återanslutning.

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:

Active-Active och Bridge-VLAN: Varje nod skriver sina egna loggar. I SFOS 22 Active-Active hanterar endast Primary trafik som tas emot på VLAN-gränssnitt konfigurerade på Bridge Interfaces. Installations- och gränssnittsbeskrivningarna för SFOS 23 utelämnar denna begränsning, men det bekräftar inte lastbalansering. Planera försiktigt för att endast Primary hanterar denna trafik och räkna inte med fördelning vid kapacitetsplaneringen förrän Sophos Support har bekräftat beteendet för aktuell SFOS 23-build och topologi.

Åtkomst till karantänen: Varje nod lagrar sin egen karantän och skickar sin egen Quarantine Digest. Administratörer frisläpper ett mejl på noden som behandlade det. Användare frisläpper mejl i karantän via User Portal. User Portal visar endast mejl i karantän på aktuell Primary.

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 dig inte 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 gäller enligt Sophos 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.

Förutsättning för att följande procedurer ska vara tillämpliga: FW1 är från början både aktuell Primary och licensbärande Initial Primary; FW2 är aktuell Auxiliary. Dessa namn betecknar samma fysiska enheter under hela proceduren, även efter ett rollbyte. Målet är att åter ha FW1 som Primary och FW2 som Auxiliary. Om aktuell Primary och Initial Primary är olika enheter ska dessa procedurer inte användas på eget initiativ: fastställ först roller och licensbärare med hjälp av tillämpliga Sophos-anvisningar eller Sophos Support.

Klargör avvikelsen i dokumentationen före ominstallation: HA-FAQ för SFOS 22 och 23 kräver generellt att HA inaktiveras före ominstallation. De detaljerade Active-Passive-anvisningarna beskriver däremot, vid ominstallation av Primary och av båda noderna, ett rollbyte med Switch to passive device följt av ominstallation, utan att ange ett separat steg med Disable HA. Rollbytet är inte detsamma som inaktivering av HA; det utelämnade steget bevisar inte att det finns ett generellt säkert undantag. De följande detaljerade procedurerna behålls därför som dokumenterade men på denna punkt motsägelsefulla förlopp. Innan de utförs måste roller, Initial Primary, installerad build, säkerhetskopia, driftavbrott och återställningsväg planeras och fastställas. Klargör rätt ordningsföljd med Sophos Support om du behöver följa denna avvikande detaljprocedur. Om ordningsföljden inte är klarlagd, stoppa före rollbyte eller ominstallation; lägg inte på eget initiativ till ett steg för inaktivering i proceduren.

Om FW1 är registrerad för Central Management ska den avregistreras före var och en av de tre procedurerna. Kontrollera därefter i samma Sophos Central-/Fusion-tenant under My Products > Firewall Management > Firewalls att posten för FW1 inte längre finns. Fortsätt först därefter med säkerhetskopiering, inaktivering av HA eller rollbyte. Denna kontroll gäller registrerad Firewall Management, inte bara Synchronized Security.

Installera endast om Auxiliary FW2

1. Efter avregistreringen och kontrollen som beskrivs ovan ska säkerhetskopian från FW1 sparas externt och HA inaktiveras på FW1, aldrig på FW2.
2. Kontrollera i Advanced Shell på FW1 med service -S | grep msync att msync visar status UNTOUCHED eller STOPPED. Fortsätt inte annars.
3. Installera om FW2 med exakt samma firmwareversion inklusive build som FW1. Logga in lokalt och konfigurera endast WAN för internetåtkomst, inga LAN- eller DMZ-gränssnitt. Claima därefter FW2 om den inte redan är claimad.
4. Bygg upp HA igen med FW1 som Primary och FW2 som Auxiliary.

Installera endast om Primary FW1

1. Efter avregistrering och kontroll ska säkerhetskopian från FW1 sparas externt. Använd Switch to passive device så att FW2 tar över. Enheternas identiteter förblir oförändrade.
2. Installera om FW1 med exakt samma firmwareversion inklusive build som FW2. Logga in lokalt, konfigurera endast WAN för internetåtkomst, inga LAN- eller DMZ-gränssnitt, och claima FW1 om den inte redan är claimad.
3. Inför återställningen ska alla kablar från FW1 utom administrationsdatorn kopplas bort. Återställ säkerhetskopian, anslut kablarna igen och för tillbaka trafiken från FW2 till FW1.
4. Fabriksåterställ därefter FW2. Logga in lokalt, konfigurera endast WAN för internetåtkomst, inga LAN- eller DMZ-gränssnitt, och claima enheten om den inte redan är claimad.
5. Bygg upp HA igen med FW1 som Primary och FW2 som Auxiliary.

Installera om och uppgradera båda noderna

1. Utför avregistrering, kontroll, säkerhetskopiering och rollbyte som vid ominstallation av Primary. Installera dock målversionen inklusive målbuild på FW1. Logga därefter in lokalt, konfigurera endast WAN för internetåtkomst, inga LAN- eller DMZ-gränssnitt, och claima enheten om den inte redan är claimad.
2. Inför återställningen ska alla kablar från FW1 utom administrationsdatorn kopplas bort. Återställ säkerhetskopian där, anslut kablarna igen och för tillbaka trafiken från FW2 till FW1.
3. Till skillnad från en ren ominstallation av Primary ska FW2 nu inte bara fabriksåterställas, utan också installeras om med exakt samma målversion inklusive build som FW1. Logga in lokalt, konfigurera endast WAN för internetåtkomst, inga LAN- eller DMZ-gränssnitt, och claima enheten om den inte redan är claimad.
4. Bygg upp Active-Passive-klustret igen med FW1 som Primary och FW2 som Auxiliary. Det planerade avbrottet omfattar även detta andra steg med ominstallation och anslutning till klustret.

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. Båda de detaljerade RMA-varianterna förutsätter att den friska kvarvarande noden redan arbetar som Standalone HA: vid RMA av Auxiliary är det den friska Primary, vid RMA av Primary den friska Auxiliary. Endast för detta utgångsläge beskriver källorna claim och licensöverföring för ersättningsenheten före den senare inaktiveringen av HA respektive återställningen av den friska noden. Tillämpa inte denna ordningsföljd vid byte i ett fortfarande fungerande HA-par; där gäller FAQ:s generella krav att inaktivera HA först. Om utgångsläget inte stämmer eller är oklart, stoppa före byte eller licensöverföring och planera proceduren 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. Förbered först lokal åtkomst till ersättningsenheten. I det dokumenterade portexemplet ansluts en DHCP-kompatibel administrationsdator till Port 1 och https://172.16.16.16:4444 öppnas; WAN ansluts till Port 2 och konfigureras för internetåtkomst i Setup Assistant. Vid en annan portlayout ska administrations- och WAN-portarna användas enligt enhetsmodellen. Konfigurera inga andra gränssnitt. Claima först därefter 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. Kontrollera i samma Sophos Central-/Fusion-tenant under My Products > Firewall Management > Firewalls att posten för denna fungerande Auxiliary-enhet inte längre finns innan du fortsätter.
2. Installera samma firmware-build på ersättningsenheten och logga in lokalt. I det dokumenterade portexemplet ansluts en DHCP-kompatibel administrationsdator till Port 1 och https://172.16.16.16:4444 öppnas; konfigurera WAN på Port 2 för internetåtkomst i Setup Assistant. Vid en annan portlayout ska administrations- och WAN-portarna användas enligt enhetsmodellen. Konfigurera inga andra gränssnitt. Claima först därefter enheten 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 den tidigare Auxiliary-enheten och förbered lokal åtkomst igen: I det dokumenterade portexemplet ansluts en DHCP-kompatibel administrationsdator till Port 1 och https://172.16.16.16:4444 öppnas. Konfigurera därefter WAN på Port 2 för internetåtkomst i Setup Assistant. Vid en annan portlayout ska administrations- och WAN-portarna användas enligt enhetsmodellen. Konfigurera inga andra gränssnitt. Claima först därefter enheten 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 planeringen även följa Förbered hanteringen av hårdvarufel och RMA för Sophos korrekt.

Felsökning

Vid komplexa fel 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: Diagnostics > Tools > Troubleshooting logs > Select files 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: Endast vid den ovan beskrivna uppbyggnaden med en ny virtuell HA spare dokumenterar Sophos detta meddelande direkt efter Initiate HA på Primary, innan spare-enheten ansluter; tillfällig status Standalone beskrivs också där. Det innebär inte att meddelandet generellt kan ignoreras. Om det kvarstår efter att spare-guiden har slutförts och väntetiden samt uppdateringen av WebAdmin har passerat, eller om det visas vid en annan uppbyggnad, kan Dedicated HA link vara frånkopplad eller den andra noden otillgänglig. Säkerställ att båda enheternas dedikerade HA-Link-gränssnitt är anslutna direkt med Ethernet-kabel eller via den avsedda switchen. Kontrollera på båda noderna under Network > Interfaces att det valda HA-Link-gränssnittet visar Connected. Använd Ping-verktyget under Diagnostics > Tools på Primary för att kontrollera Auxiliarys dedikerade HA-Link-IP-adress, inte dess Peer Admin-adress. Svar bekräftar grundläggande nåbarhet, men inte att HA-synkroniseringen är slutförd. Om svar uteblir ska först kabel, switchväg, länkstatus och HA-Link-IP/subnät kontrolleras och korrigeras; upprepa därefter Ping och kontrollera roller och synkronisering igen.

• 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: Sök efter exakt detta meddelande i /log/syslog.log på Primary. Sophos kopplar det till administrationsportar som inte ligger i samma subnät; jämför båda enheternas administrationsportadresser. Kontrollera dessutom, som ett separat krav, att HA-Link-adresserna ligger i samma subnät, men behandla inte dessa adresser som en belagd orsak till meddelandet. Före korrigering av administrationsadresser ska den ovan beskrivna förkontrollen för att klargöra källkonflikten genomföras: dokumentera roller, installerad SFOS-build, administrationsgränssnitt och aktuella IP-adresser, säkra en säkerhetskopia och separat konsol-/lokal administrationsåtkomst och verifiera det tillämpliga adressbeteendet eller klargör det med Sophos Support. Om beteendet inte är klarlagt, stoppa före adressändringar.

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

WebAdmin och VPN Portal kan inte nås vid certifikatsynkronisering

Versionsinformationen för SFOS 22.0 MR3 Build 576 från den 16 oktober 2026 anger NC-186809 som åtgärdat: Certifikatsynkroniseringen på Auxiliary kunde misslyckas när vissa certifikatfilnamn började med två punkter i följd (..); detta gjorde att WebAdmin och VPN Portal inte kunde nås. Skilj detta felmönster från allmänna routing- eller Device Access-problem och spara build, berörd nod, tidpunkt och tillgängliga synkroniseringsloggar. Byt inte namn på eller ta bort certifikat på försök. Vid en motsvarande misstanke bör supporten involveras och ett firmwarebyte som stöds planeras med säkrad administrationsåtkomst; kontrollera därefter båda portalerna och HA-synkroniseringen igen.

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.

Leta i samma utdata från show network interfaces upp det berörda fysiska gränssnittet med hjälp av dess faktiska gränssnittsnamn och kontrollera, utöver länkstatus, de tillgängliga räknarna för paketförluster (Drops), fel och kollisioner. Alla buildar visar inte alla räknare; saknade uppgifter är inte ett nollvärde. Spara utdata med nod, gränssnitt och tidsstämpel och jämför med en senare observation: ökande räknarvärden hjälper till att ringa in gränssnitts-, kabel- eller förhandlingsproblem, men bevisar inte i sig en specifik orsak. Utför kabelbyte eller korrigering av Speed/Duplex endast kontrollerat, med säkerställd administrationsåtkomst och de ovan beskrivna försiktighetsåtgärderna för HA/Split-Brain; jämför därefter räknare, länkstatus, roller och synkronisering igen. Dessa gränssnittsräknare ska skiljas från paket som blockeras av brandväggsregler och tillhörande Drop Capture.

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.

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