Konfigurera och testa WAN-failover i Sophos Firewall
En andra internetanslutning blir inte automatiskt en reservanslutning i Sophos Firewall. En ny WAN-gateway är som standard Active och deltar därför i Load Balancing. För en klassisk Primary/Backup-design måste den andra gatewayen ställas om till Backup i WAN link manager.
Den snabba vägen till en huvud- och en reservanslutning:
- Konfigurera båda WAN-gränssnitten fullständigt under Network > Interfaces och testa dem var för sig.
- Ange huvudgatewayen som Active och reservgatewayen som Backup under Network > WAN link manager.
- Välj Activate this gateway: If active gateway fails: ANY för reservgatewayen.
- Konfigurera tillförlitliga Failover rules för båda gatewayarna.
- Testa failover och failback – det vill säga återgången till huvudanslutningen – med verklig DNS-, HTTPS- och applikationstrafik.
För enkel failover av standardanslutningen till internet behövs ingen separat SD-WAN-rutt. SD-WAN behövs när viss trafik ska använda specifika vägar eller när vägvalet ska styras av latens, jitter och paketförlust.
Förstå Active, Backup och Load Balancing
Gatewaytypen avgör om en anslutning normalt deltar i internettrafiken:
- Active: Om flera aktiva gateways är tillgängliga fördelar brandväggen nya sessioner enligt de konfigurerade vikterna.
- Backup: Gatewayen tar över först när dess aktiveringsvillkor är uppfyllt.
Minst en WAN-gateway måste vara Active. Om alla gateways endast är markerade som Backup saknas den normala standardvägen via WAN. Då kan i synnerhet trafik från själva brandväggen inte vidarebefordras.
Weight beskriver inte bandbredden. I läget weighted round-robin innebär förhållandet 2 till 1 att brandväggen tilldelar två nya sessioner till den första gatewayen och nästa session till den andra. En enskild nedladdning delas därför inte mellan båda anslutningarna, och den överförda datamängden kan avvika tydligt från detta förhållande.
Sophos Firewall använder Session Persistence som standard. Det innebär att inte bara en enskild befintlig anslutning stannar på samma WAN-länk. Beroende på Persistence Factor kan exempelvis även nya sessioner från samma Source IP åter tilldelas denna länk. Den aktuella metoden visas efter inloggning under Option 4: Device Console med ett skrivskyddat kommando:
show routing wan-load-balancing
Kommandot ändrar ingenting. Det visar om Session Persistence eller weighted round-robin är aktivt och hjälper därmed till att förklara en oväntad vägfördelning. I en ren Active/Backup-design är metoden oftast av mindre betydelse eftersom endast en avsedd väg är tillgänglig vid både normaldrift och fel.
WAN-failover är inte samma sak som HA-failover. WAN link manager byter internetväg på samma brandvägg. Ett Sophos Firewall HA-kluster tar däremot över när en enhet eller en övervakad port slutar fungera.
Förbered WAN-failover
Båda operatörsanslutningarna måste först fungera oberoende av varandra. Grunderna för WAN-zon, IP-tilldelning och gateway finns i Planera zoner och gränssnitt i Sophos Firewall.
Ett enkelt exempel kan se ut så här:
WAN1 Fiber: huvudanslutning, gatewaygw-fiber, Type: Active, Weight: 1WAN2 DSL: reservanslutning, gatewaygw-dsl, Type: Backup- aktivering av reservanslutningen: If active gateway fails: ANY
- åtgärd vid aktivering: Inherit weight of the failed active gateway
- åtgärd när huvudanslutningen återkommer: Serve new connections through restored gateway
Namnen kan väljas fritt och bör tydligt beskriva anslutningen. Gatewaytyp och åtgärder är däremot funktionella inställningar. Innan omkopplingen ska reservgatewayen redan ha grön status och verklig klienttrafik ha testats framgångsrikt via anslutningen.
Det behövs också en säker returväg för administrationen. Om brandväggen ändras på distans bör WebAdmin inte enbart vara åtkomligt via den anslutning som kopplas bort under testet. En aktuell konfigurationsbackup, ett underhållsfönster och en person på plats eller en oberoende hanteringsväg förhindrar att ett enkelt failover-test leder till ett längre avbrott.
Notera också i förväg alla tjänster som är bundna till en offentlig IP-adress. Det gäller bland annat DNAT-publiceringar, IPsec-motparter, Remote Access, operatörsallowlists, e-postservrar och externa övervakningssystem. Utgående internetåtkomst kan redan fungera samtidigt som dessa tjänster ännu inte är åtkomliga eller tillåtna via den nya offentliga adressen.
Konfigurera Primary/Backup
Kontrollera WAN-gränssnitt och gatewaystatus
Konfigurera båda WAN-portarna under Network > Interfaces med den statiska, DHCP- eller PPPoE-konfiguration som operatören anger. När inställningarna sparas skapas den tillhörande fysiska WAN-gatewayen automatiskt i WAN link manager.
En ny gateway är först Active. När en ren reservanslutning har lagts till bör typen därför ändras direkt, innan produktionstrafik oavsiktligt fördelas mellan båda operatörerna.
Custom Gateways från Routing > Gateways, till exempel för XFRM, RED eller MPLS, visas inte i WAN link manager. De ingår i en annan routingdesign och behandlas inte som fysiska ISP-gateways i detta enkla scenario.
Konfigurera reservgatewayen
Redigera reservanslutningens gateway under Network > WAN link manager och ange följande värden:
- Type:
Backup - Activate this gateway:
If active gateway fails - Med en huvudanslutning:
ANY - Action on activation:
Inherit weight of the failed active gateway - Action on failback:
Serve new connections through restored gateway - Spara och kontrollera gatewaystatus.
Med exakt en aktiv gateway har ANY och ALL i praktiken samma effekt. Skillnaden blir viktig med flera aktiva anslutningar:
- ANY: Reservgatewayen aktiveras så snart en av de aktiva gatewayarna fallerar. Det passar när förlorad kapacitet ska ersättas omedelbart.
- ALL: Reservgatewayen aktiveras först när alla aktiva gateways har fallerat. Det passar bättre för en långsam eller dyr nödanslutning.
Action on activation avgör reservgatewayens vikt när den aktiveras tillsammans med andra tillgängliga gateways. Inherit weight of the failed active gateway är ett tydligt val för ett enkelt ersättningsscenario. Use configured weight är lämpligt när reservanslutningen medvetet har lägre eller högre kapacitet och arbetar tillsammans med återstående aktiva anslutningar.
Vid failback är Serve new connections through restored gateway det skonsammare alternativet i drift. Nya sessioner använder åter huvudanslutningen, medan befintliga sessioner ligger kvar på reservvägen tills de når timeout eller avslutas. Serve all connections through restored gateway etablerar befintliga anslutningar på nytt och kan avbryta dem. För SD-WAN-rutter gäller denna åtgärd endast om WAN link load balance har valts som Primary Gateway. Om en enskild Active WAN-länk är vald som Primary går endast nya anslutningar via den återställda gatewayen.
Välj lämpliga Failover rules
Failover rules avgör när en gateway betraktas som oåtkomlig. Följande alternativ finns:
- Testing method:
PingellerTCP - IP address
- för TCP dessutom Port
- kombination av flera felvillkor med AND eller OR
Ett fysiskt kabelavbrott identifieras redan av gränssnittet. Det Ping-test av gatewayens IP-adress som skapas som standard kontrollerar dessutom om den direktanslutna operatörsenheten eller första operatörshoppet är nåbart. Testet kan dock förbli grönt trots att internetåtkomsten bakom den nåbara operatörsroutern har slutat fungera. Sophos rekommenderar därför ett känt offentligt IP-mål för WAN-/ISP-gateways, till exempel 8.8.8.8 eller 8.8.4.4.
För IPv6 anger Sophos 2001:4860:4860::8888 som ett offentligt exempel. För att kontrollera upstream-enheten ska gatewayens IPv6-adress användas, inte dess link-local-adress.
Ett enda mål ger inte heller en fullständig statuskontroll. En robustare utgångspunkt är två permanent nåbara offentliga IP-adresser som är godkända i organisationen:
- AND: Failover utlöses först när alla sammanlänkade kontroller misslyckas. Det minskar risken för felaktiga omkopplingar på grund av ett enda oåtkomligt mål.
- OR: Redan en misslyckad kontroll kan utlösa failover. Det reagerar känsligare men ökar risken för onödiga omkopplingar.
8.8.8.8 och 8.8.4.4 är konkreta Sophos-exempel, men tillhör samma operatör och utgör därför inte helt oberoende feldomäner. I en viktig miljö är två godkända mål hos olika operatörer bättre. Ett Ping-mål måste svara tillförlitligt på ICMP. För TCP krävs en stabil tjänst vars port får kontrolleras.
ANY/ALL för reservgatewayen och AND/OR för kontrollreglerna besvarar olika frågor. ANY/ALL avgör hur många aktiva gateways som måste fallera. AND/OR avgör hur flera kontroller bedömer avbrottet för en enskild gateway.
Det globala värdet Gateway failover timeout i WAN link manager avgör när brandväggen betraktar en länk som inte svarar som otillgänglig. Det finns inget universellt korrekt värde. En kort timeout reagerar snabbare men kan orsaka onödiga omkopplingar vid paketförlust eller en kort störning i testmålet. Värdet används bland annat även som Health Check-intervall för IPsec-failovergrupper och bör därför inte ändras isolerat för en enskild WAN-länk. Dokumentera utgångsvärdet, testa kontrollerat och justera först därefter utifrån den uppmätta omkopplingstiden.
Testa failover och failback kontrollerat
Ett kabeltest kontrollerar endast ett lokalt länkavbrott. En operatörsstörning bakom en router som fortfarande är nåbar upptäcks först när även de konfigurerade offentliga testmålen inte längre kan nås. Båda fallen bör därför helst testas separat.
- Bekräfta underhållsfönster, återställningsplan och alternativ administrationsåtkomst.
- Dokumentera status för huvud- och reservgateway under Network > WAN link manager.
- Testa DNS, HTTPS och en viktig applikation från en testklient. Notera även vilken offentlig utgående adress som används.
- Koppla kontrollerat bort den primära WAN-kabeln för länktestet. Låt anslutningen till brandväggen vara aktiv för det egentliga övervakningstestet och bryt i stället uppströmsanslutningen bakom operatörsenheten om detta kan göras säkert.
- Vänta längre än den konfigurerade Gateway failover timeout.
- Kontrollera att huvudgatewayen visas som otillgänglig och reservgatewayen som aktiv.
- Starta nya DNS-, HTTPS-, VPN- och applikationssessioner. Kontrollera brandväggsregel, NAT, åtkomst till målet och den nya offentliga utgående adressen.
- Kontrollera Gateway Up/Down-händelser i Log viewer. För en djupare analys innehåller
dgd.loghändelser för hantering av WAN-gateways och Link Failover. - Återställ huvudanslutningen och kontrollera befintliga och nya sessioner separat. Då blir det tydligt om det konfigurerade failback-beteendet verkligen inträffar.
- Dokumentera slutstatus, applikationer och extern åtkomst.
Ett lyckat Ping-test visar endast att testmålet svarar. Det bekräftar varken DNS, NAT, VPN, publicerade tjänster eller en verksamhetsapplikation. För den faktiska paketvägen hjälper Packet Capture i Sophos Firewall WebAdmin. Information om dgd.log och andra filer finns i Sophos Firewall Service Logs.
Vanliga fel och begränsningar
- Reservanslutningen fördelar redan produktionstrafik: Den nya gatewayen är fortfarande Active. Ändra den till Backup för en ren reservanslutning.
- Reservgatewayen aktiveras inte vid ett avbrott: Kontrollera gatewaystatus, typ,
ANY/ALL, Failover rules och Gateway failover timeout. Med flera aktiva gateways kanALLavsiktligt förhindra aktivering så länge en aktiv väg fortfarande är tillgänglig. - Gatewayen är grön men internet fungerar inte: Testmålet är nåbart medan DNS, routing, brandväggsregel, NAT eller applikationen misslyckas. Kontrollera verklig trafik, Log Viewer och Packet Capture.
- Brandväggen växlar utan en verklig operatörsstörning: Ett enda testmål svarar inte,
ORär för känsligt eller timeout-värdet är för kort för anslutningens kvalitet. Kontrollera testmålen och den uppmätta paketförlusten. - Befintliga sessioner bryts vid omkopplingen: Den offentliga Source IP-adressen eller NAT-tillståndet ändras. Motparter kan därför avvisa anslutningen. WAN-failover ger inte automatiskt Zero Downtime.
- Utgående trafik fungerar men inkommande tjänster gör det inte: Den andra operatören behöver rätt offentlig åtkomst, DNS eller Dynamic DNS, DNAT, brandväggsregler och eventuellt certifikat. DNAT för publicerade servrar och Grunderna i NAT hjälper till att avgränsa felet.
- VPN fungerar endast via huvudanslutningen: Remote Gateway, lokal Listening Address, FQDN, identiteter, tunnelkonfiguration och returväg måste även stämma för reservvägen. Enkel WAN-failover skapar ingen andra VPN-anslutning.
Om applikationer, användargrupper eller målnät ska använda olika anslutningar eller om latens, jitter och paketförlust ska styra vägvalet hör beslutet hemma i SD-WAN-rutter och profiler i Sophos Firewall. För en mobil reservanslutning tillkommer SIM, APN, datamängd, CGNAT och signalkvalitet. Dessa punkter beskrivs i Cellular WAN och 4G/5G-failover.
Drift
- Skicka vid behov meddelanden om ändrad gatewaystatus via e-post. Konfigurera först e-postserver, avsändare och mottagare under Administration > Notification settings. Aktivera därefter den globala inställningen Email notifications under System services > Notification list och välj händelsen Gateway status under System. En markerad händelserad skickar inte ensam något e-postmeddelande.
- Kontrollera gatewaystatus och
dgd.logefter oplanerade omkopplingar. - Testa failover och failback minst varje kvartal samt efter ändringar av operatör, gränssnitt, NAT, routing eller firmware.
- Dokumentera beroenden till offentliga IP-adresser, VPN-motparter, allowlists och inkommande tjänster.
- Utse ansvariga för operatörsstörningar, eskalering och återgång till normal drift.
- Kontrollera testmålen regelbundet. Ett mål som har förändrats permanent eller inte längre är nåbart får inte obemärkt styra omkopplingslogiken.
- Kontrollera vikter och Session Persistence utifrån verklig användning när flera aktiva anslutningar används, inte bara utifrån nominell bandbredd.