Hoppa till innehållet
Avanet

Konfigurera och verifiera en SD-WAN-anslutningsgrupp i Sophos Fusion

Med en SD-WAN-anslutningsgrupp kan Sophos Fusion (tidigare Sophos Central) bygga route-based IPsec-anslutningar mellan flera hanterade brandväggar. Det minskar mängden upprepad konfiguration i hub-and-spoke- och full-mesh-topologier. Sophos Fusion kan generera tunnlar, XFRM-gränssnitt, routes, nätverksobjekt och, om alternativet väljs, tillhörande brandväggsregler.

Automatiseringen ersätter inte nätverksplanering och verifiering. En grön gruppstatus bekräftar främst att de deltagande brandväggarna är aktiva. Den bevisar inte att en viss klient kan nå fjärrmålet via förväntad regel, route och NAT-behandling.

Snabbväg till en fungerande anslutningsgrupp

  1. Kontrollera rollen Admin eller Super Admin, SFOS 20.0 eller senare, Central Orchestration-licensen, Sophos Fusion-hantering och gruppmedlemskap för alla brandväggar; i AWS eller Azure krävs BYOL i stället för PAYG.
  2. Dokumentera lokala nät, WAN-adresser, NAT-förhållanden, redundans och önskad topologi.
  3. Säkerställ att XFRM-adresspoolerna inte överlappar något produktionsnät.
  4. Skapa en grupp under My Products > Firewall Management > SD-WAN Connection Groups.
  5. Välj brandväggar, delade resurser, tjänster och valfritt automatisk generering av brandväggsregler.
  6. Lös varje nätverks- och WAN-konflikt som Sophos Fusion upptäcker separat.
  7. Övervaka Tasks Queue och gruppstatus tills alla deltagande brandväggar har bearbetats.
  8. Kontrollera tunnlar, Central_-objekt, XFRM-adresser, routes och regler på varje brandvägg.
  9. Generera verklig dubbelriktad trafik och kontrollera Firewall Rule ID, route, NAT och returväg.
  10. Lägg till fler resurser eller brandväggar först efter att det första omfånget har verifierats.

⚠️ Ta inte bort en aktiv anslutningsgrupp utan planering och avregistrera inte en brandvägg från Sophos Fusion under normal drift. När en brandvägg avregistreras tar Sophos Fusion bort den tillhörande anslutningsgruppen och dess automatiskt skapade tunnlar. En sådan ändring kräver en aktuell säkerhetskopia, ett underhållsfönster och en dokumenterad återställningsväg.

Vad Sophos Fusion skapar automatiskt

En SD-WAN-anslutningsgrupp använder route-based IPsec VPN. Beroende på topologin skapar Sophos Fusion de anslutningar och konfigurationsobjekt som behövs på medlemsbrandväggarna. Automatiskt genererade objekt har namn med prefixet Central_ i den lokala konfigurationen. De omfattar bland annat IPsec-anslutningar, XFRM-gränssnitt, nätverksobjekt och routes.

I en hub-and-spoke-topologi finns de delade resurserna bakom hubbrandväggen. Normalt svarar hubben som remote gateway på tunnlar som initieras av spokes. Detta passar till exempel ett huvudkontor med servernät och flera filialer. Rollerna följer normalt av de delade resurserna: brandväggen som delar en resurs är responder. Ett undantag gäller vid dynamisk WAN-adress med wildcard-åsidosättning: då förblir även den resursdelande brandväggen initiator; förutsättningarna finns i avsnittet Lös nätverks- och WAN-konflikter.

I en full mesh, när båda brandväggarna delar resurser, tilldelar Sophos Fusion responderrollen alfabetiskt efter hostname. Om namnen är identiska används brandväggs-ID:n i alfabetisk ordning. Detta kan möjliggöra direkta platsvägar men skapar fler tunnlar och beroenden. Hostname bör därför vara stabila och unika; rollerna väljs inte fritt per tunnel.

Alternativet att skapa brandväggsregler automatiskt är praktiskt, men ersätter inte en kontroll av tillåtna källor, mål och tjänster. Om alternativet inte väljs måste nödvändiga regler finnas lokalt eller i den ansvariga Sophos Fusion-gruppolicyn. Om alternativet väljs måste de genererade reglerna ändå kontrolleras avseende ordning, omfattning och loggning. Grunderna beskrivs i Planera och skapa brandväggsregler på Sophos Firewall.

Planera topologi och exempelvärden

Följande exempelgrupp ansluter tre brandväggar:

  • FW-HQ delar servernätet 10.10.0.0/16.
  • Filialnätet 10.20.0.0/16 bakom FW-BE ska få åtkomst till den delade resursen.
  • Filialnätet 10.30.0.0/16 bakom FW-ZH ska också få åtkomst till den.
  • Inledningsvis behövs endast HTTPS och RDP till utvalda system i servernätet.
  • Exemplet använder hub-and-spoke med FW-HQ som hubb.

Dessa namn och nät är endast dokumentationsvärden. De ska ersättas med faktiska brandväggsnamn, lokala resurser och tjänster. Planeringen gäller inte bara direkta överlappningar mellan de tre platserna. Även fjärranslutna moln-, partner-, VPN-klient-, RED- och hanteringsnät måste jämföras med de planerade resurserna och XFRM-poolerna.

Förstå XFRM-adresspooler

Sophos Fusion använder /30-nät för XFRM-gränssnitten. Om ingen egen pool har angetts använder Sophos Fusion som standard 10.252.0.0/15 och 10.254.0.0/16. Om något av dessa intervall redan finns i miljön ska en ledig anpassad pool väljas innan den första gruppen skapas. Flera pooler kan läggas till; när en är slut använder Sophos Fusion nästa.

Inställningen finns under:

My Products > Firewall Management > SD-WAN Connection Groups > Add IP Pool

En pooländring påverkar endast nya anslutningsgrupper. Befintliga grupper behåller sina tilldelade XFRM-adresser. Att ändra poolen är därför inte en retroaktiv reparation av en produktionsgrupp.

Förutsättningar före skapandet

Det orkestreringsflöde som beskrivs här kräver SFOS 20.0 eller senare på alla deltagande brandväggar, Sophos Fusion-hantering och en giltig Central Orchestration-licens. Den äldre minimiangivelsen SFOS 18.5 MR1 är inget versionsgodkännande för detta flöde. För Sophos Firewall i AWS eller Azure stöds BYOL (Bring Your Own License); PAYG (Pay As You Go) stöds inte för SD-WAN Orchestration. Kontrollera därför driftsättnings- och licensmodell, inte bara SFOS-versionen, innan en molnbrandvägg läggs till.

Sophos Fusion kräver rollen Admin eller Super Admin för att skapa den nödvändiga brandväggsgruppen och öppna dess policy. Varje anslutningsgrupp kräver minst två brandväggar som redan tillhör en Sophos Fusion-brandväggsgrupp. En registrerad men ej grupptilldelad brandvägg kan inte läggas till.

Kontrollera även följande före skapandet:

  • nåbar publik IP-adress eller FQDN för varje WAN-väg
  • NAT uppströms och den resulterande initiator- eller responderrollen
  • unika lokala resurser utan överlappning
  • lediga XFRM-nät
  • aktiva WAN-länkar och planerade backup-gateways
  • tjänster som är tillåtna mellan platserna
  • befintliga lokala IPsec-, routing-, NAT- och SD-WAN-konfigurationer
  • oberoende hanteringsåtkomst och en aktuell konfigurationsbackup

Konfigurera en site-to-site IPsec VPN på Sophos Firewall förklarar uppbyggnaden av en enskild route-based anslutning. I en anslutningsgrupp utför Sophos Fusion många av dessa steg, men de underliggande kraven på routing, regler och returväg är desamma.

Skapa anslutningsgruppen i Sophos Fusion

Välj brandväggar och resurser

Börja här:

My Products > Firewall Management > SD-WAN Connection Groups > Create Connection Group

Ge gruppen ett entydigt namn, till exempel HQ-Branches, och valfritt en beskrivning. Välj sedan minst två brandväggar. För varje brandvägg anges den IP-adress eller nätverksrange som ska vara tillgänglig för övriga platser som Shared resources. I exemplet delar endast FW-HQ servernätet, vilket bestämmer hub-and-spoke-rollerna.

Välj resurser så snävt som möjligt. I stället för att dela hela huvudkontorets nät räcker ofta ett server- eller applikationsnät. Välj inte heller Any för tjänster av försiktighetsskäl när endast ett fåtal applikationer behövs.

Sophos Fusion kan valfritt skapa brandväggsregler. Alternativen omfattar även autentiserade användare och Security Heartbeat. Dokumentera före sparandet om regler genereras automatiskt eller hanteras separat. Då är det senare tydligt om en saknad regel är ett fel eller ett designbeslut.

Lös nätverks- och WAN-konflikter

Sophos Fusion kontrollerar de valda resurserna och WAN-anslutningarna efter konflikter. En konflikt betyder inte automatiskt att ett nät är felaktigt. Den innebär att Sophos Fusion inte kan generera en entydig anslutning utan ett ytterligare beslut.

Beroende på resultatet kan bland annat följande beslut vara möjliga:

  • stänga av ett överlappande subnät för denna anslutning
  • koppla en unik NAT-adress till subnätet
  • definiera ett ytterligare nätverksobjekt
  • välja rätt WAN-länk
  • välja en backup-gateway
  • åsidosätta adressen som Sophos Fusion har identifierat

På den brandvägg som delar resursen erbjuder guiden endast att slå på eller av nätet, inte att tilldela NAT. Om det överlappande nätet ska fortsätta delas måste adresskonflikten först lösas på denna brandvägg eller i nätverksdesignen. Att bara slå på nätet löser inte överlappningen. På den brandvägg som använder resursen kan NAT-alternativet användas för konfliktlösning. Kontrollera därför före sparandet för varje överlappande nät vilken brandvägg som delar det, vilken som använder det och om den valda åtgärden faktiskt löser konflikten. Om ett nät i stället utesluts blir det inte tillgängligt via denna anslutningsgrupp.

Varje beslut ändrar den resulterande datavägen. NAT-adresser, WAN-åsidosättningar och avstängda nät dokumenteras därför i en adress- och routingplan, i stället för att bara konfigureras tills statusen blir grön.

Ett jokertecken * i Public IP or FQDN for selected WAN link är endast tillåtet när remote-gateway-brandväggen är responder och kör minst SFOS 20.0. En resursdelande brandvägg med dynamisk WAN-adress och wildcard-åsidosättning förblir initiator och använder IPsec-profilen Central_DefaultBranchOffice. Motparten måste vara responder och köra SFOS 20.0 eller senare. Resursdelningen gör alltså inte i sig den dynamiska brandväggen till responder i detta fall.

Dokumentera den dynamiska lokala brandväggen, dess initiatorroll och den nåbara respondermotparten med SFOS-version för varje WAN-väg innan * anges. Kontrollera efter driftsättningen att roller, profil och WAN-tilldelning i de genererade IPsec-anslutningarna motsvarar planen, och testa resursvägen med verklig applikationstrafik. Jokertecknet får inte användas för att dölja en oklar WAN- eller NAT-situation. Initiator, publik nåbarhet och peeridentitet måste fortfarande vara entydiga; centralt genererade profiler ska inte skrivas om generellt lokalt.

Spara gruppen och övervaka uppgifter

Efter att gruppen har sparats skapar Sophos Fusion de uppgifter som krävs för alla deltagande brandväggar. Under processen hålls den befintliga administratörssessionen öppen på minst en brandvägg. Kontrollera anslutningsgruppens status och detaljer i Sophos Fusion samt:

My Products > Firewall Management > Tasks Queue

Hoppa inte bara över Pending, Failed eller Partial Success. Dokumentera brandvägg, entitet, fel och tidpunkt och jämför dem med den lokala konfigurationen. Kontrollera Sophos Fusion Firewall Tasks Queue förklarar Retry, Skip, Force Sync och lokal verifiering i detalj.

Efter att uppgifterna är klara kontrolleras även tunnelstatus: GOOD betyder att VPN-tunneln är upprättad; DOWN betyder att den inte är upprättad eller att anslutningen har förlorats. UNKNOWN betyder däremot att inga Heartbeat-uppgifter har kommit in på ungefär fem minuter, så att Sophos Fusion inte kan avgöra tunnelstatusen. Detta är varken ett bevisat tunnelavbrott eller ett godkänt funktionstest. För godkännande måste de förväntade tunnlarna visa GOOD och klara de lokala kontrollerna nedan.

Verifiera den genererade konfigurationen lokalt

Efter en lyckad Sophos Fusion-uppgift öppnas varje deltagande brandvägg separat. Kontrollera följande:

  1. De förväntade Sophos Fusion-anslutningarna är aktiva under Site-to-site VPN > IPsec.
  2. XFRM-gränssnitten har unika /30-adresser från den planerade poolen under Network > Interfaces.
  3. De genererade routes pekar via det förväntade XFRM-gränssnittet under Routing.
  4. Nätverks-, värd- och tjänsteobjekt med Central_ motsvarar de delade resurserna.
  5. Automatiskt eller separat skapade brandväggsregler tillåter endast planerade källor, mål och tjänster.
  6. NAT används endast där det medvetet valdes för att lösa en konflikt.
  7. Vid flera WAN-vägar motsvarar gateway- och SD-WAN-status det planerade primära valet och backupvalet.

Om en grupp innehåller både Shared resources och Participating networks skapar brandväggen två liknande SD-WAN-routes: en för de delade resurserna och en för de deltagande näten. Det är förväntat deploymentbeteende, inte en dubblett som ska raderas lokalt utan undersökning.

Sophos Fusion hanterar de genererade objekten. Manuella lokala ändringar av Central_-objekt kan skrivas över vid en senare gruppändring eller skapa inkonsekvenser. Ändringar ska därför göras i anslutningsgruppens design eller i den ansvariga Sophos Fusion-policyn.

Verifiera med verklig trafik

Vid den första verifieringen genomförs minst ett verkligt test för varje väg till en delad resurs. I exemplet ansluter en klient från 10.20.0.0/16 via HTTPS till en uttryckligen tillåten server i 10.10.0.0/16; därefter utförs ett test från 10.30.0.0/16.

Kontrollera på båda sidor:

  • aktiva IKE- och Child-SA
  • rätt Firewall Rule ID
  • inkommande och utgående gränssnitt i Packet Capture
  • förväntade käll- och måladresser efter en medveten NAT-översättning
  • fram- och returväg
  • applikationsresultatet, inte bara en ping

En grön tunnel- eller gruppstatus är bara ett delresultat. Testa en regel på Sophos Firewall beskriver den fullständiga verifieringen med Log Viewer, Policy Test och Packet Capture.

Lägg till SD-WAN-profiler och redundans

Minimiversionerna nedan gäller enskilda profilfunktioner och ersätter inte kravet på SFOS 20.0 eller senare för det orkestreringsflöde som beskrivs här.

Sophos Fusion stöder SD-WAN-profiler för anslutningsgrupper från SFOS 19.0. Routingstrategin är tillgänglig från SFOS 19.5. Sophos Fusion skapar gatewayen för VPN-tunneln automatiskt; välj en befintlig gateway på brandväggen som backup. Profilen kan använda First available gateway eller Load balancing; lastbalansering erbjuder round-robin och flera typer av sessionspersistens. Den ersätter inte en korrekt route eller en fungerande VPN-anslutning.

XFRM-adressen måste ligga i ett /30-subnät. Annars visar Sophos Fusion Migrate och tilldelar under migreringen alla tunneladresser från 10.252.0.0/15 och 10.254.0.0/16. Migreringen och varje profiländring förändrar datavägen: säkra först backup och out-of-band-åtkomst, ändra en plats eller väg i ett underhållsfönster, kontrollera Sophos Fusion-uppgifter och lokal konfiguration och utöka först därefter utrullningen.

Testa varje WAN- och tunnelväg separat innan en profil aktiveras. Kontrollera sedan med verklig trafik att nya anslutningar använder den avsedda vägen och växlar som planerat vid ett planerat avbrott. Health checks använder Ping eller TCP och högst två probe targets bakom gatewayen. Om ett mål är en publik IP-adress behöver målbrandväggen en regel från VPN-zonen till WAN-zonen. Om ingen gateway uppfyller det anpassade SLA-värdet använder brandväggen strategin First available gateway. Kontrollera detta beteende i ett planerat failovertest.

Den lokala routinglogiken, SLA-värdena och failover-verifieringen beskrivs i Konfigurera en SD-WAN-route på Sophos Firewall. Sophos Fusion förenklar distributionen, men ändrar inte innebörden av gateway, route precedence, NAT eller sessionsbeteende.

Felsök efter symptom

En brandvägg kan inte väljas

Kontrollera Sophos Fusion-registreringen, en giltig licens eller Orchestration-behörighet och medlemskapet i en Sophos Fusion-brandväggsgrupp. Kontrollera sedan om en öppen grupp- eller synkroniseringsuppgift blockerar ändringen.

En uppgift misslyckades eller lyckades bara delvis

Skapa inte omedelbart om gruppen. Spara först uppgiftsdetaljerna och den partiella lokala konfigurationen. Vanliga orsaker är objekt- eller nätverkskonflikter, onåbara brandväggar, licensbegränsningar eller en gruppolicy som inte kunde tillämpas fullständigt. Försök igen först när orsaken har korrigerats.

Tunnelstatus är UNKNOWN

Kontrollera först Sophos Fusion-anslutningen, Heartbeat och synkroniseringsstatus för berörda brandväggar samt Tasks Queue. Kontrollera samtidigt den lokala tunnelstatusen under Site-to-site VPN > IPsec via den oberoende hanteringsåtkomsten och genomför det dokumenterade applikationstestet. Om den lokala tunneln och nyttotrafiken fungerar saknas i första hand centralt statusunderlag; gruppen ska inte raderas eller skapas om enbart på grund av UNKNOWN. Om anslutningen också är störd lokalt kontrolleras WAN-nåbarhet, IKE-/Child-SA och datavägen. Kontrollera på nytt om Sophos Fusion visar GOOD när Heartbeat-överföringen har återställts. Om UNKNOWN kvarstår trots en fungerande anslutning, spara status, tidpunkter och uppgiftsdetaljer för fortsatt felsökning.

Tunneln är aktiv men applikationstrafiken saknas

Jämför delade resurser, tjänsteval och brandväggsregel med det verkliga flödet. Kontrollera sedan route, XFRM-gränssnitt, NAT, route precedence och returväg. En ping är bara meningsfull om ICMP är tillåtet och målet förväntas svara.

Endast en WAN- eller backupväg fungerar

Kontrollera publik adress eller FQDN, NAT uppströms, gatewayroll, WAN-länk och backup-gateway. För en SD-WAN-profil fortsätter kontrollen med SLA-målet och gatewaystatusen. Ett jokertecken eller en grön tunnel får inte dölja bristande end-to-end-nåbarhet.

En pooländring syns inte i gruppen

Detta är förväntat för befintliga anslutningsgrupper. Nya IP-pooler används endast av grupper som skapas senare. Ta inte bort och återskapa en produktionsgrupp enbart för att ändra adresseringen; planera först påverkan, avbrott och återställning.

Sophos Fusion är grön men applikationen är fortfarande otillgänglig

Gruppstatusen är inte applikationsövervakning. Kontrollera samtidigt loggar, Rule IDs, Packet Capture, routing och NAT på båda brandväggarna. Vid HA eller distribuerad bearbetning används den nod som hanterade testtrafiken.

Genomför ändringar och återställ säkert

Före en större gruppändring dokumenteras anslutningsgruppens konfiguration, brandväggsmedlemmar, delade resurser, WAN-tilldelning, XFRM-pool, automatiskt genererade regler och ett fungerande testflöde. Spara även en aktuell säkerhetskopia av brandväggen.

När en uppdatering återskapar objekt

En utökning kompletterar normalt den konfiguration som behövs; befintliga tunnlar, routes och brandväggsregler behålls så länge deras skapandekriterier inte påverkas. En ytterligare filial innebär därför inte automatiskt att alla befintliga anslutningar byggs om. Om villkoren för centralt hanterade brandväggsregler, NAT-regler eller SD-WAN-routes ändras tar Sophos Fusion däremot bort de berörda objekten och skapar dem på nytt. Det omfattar ändringar av:

  • lokala eller tillåtna källnät;
  • Shared resources eller målnät;
  • tjänster och portar;
  • användar- eller Security Heartbeat-villkor;
  • NAT för att lösa överlappande subnät;
  • backup-gateways eller tilldelningen av SD-WAN-routes till gateways.

Om exempelvis HTTPS-delningen i befintlig HQ-Branches-design ändras till en annan tjänst kan det utlösa återskapande av berörda åtkomstregler och routes; det är inte bara en ändring av beskrivningstexten. Jämför därför berörda källnät, mål, tjänster och vägar med det tidigare testflödet före sparandet. Ändringar som återskapar objekt planeras i ett underhållsfönster med möjlighet till avbrott; en oförändrad tunnel garanterar inte att åtkomsten fortfarande är rätt.

Spara endast en orkestreringsändring åt gången. Medan Sophos Fusion skapar, uppdaterar eller tar bort gruppen ska inga parallella ändringar av gränssnitt, WAN, LAN eller nät göras på brandväggarna. Kontrollera på nytt de återskapade Central_-reglerna, NAT-tilldelningarna och routes på berörda brandväggar när uppgifterna är klara, identifiera den Firewall Rule ID som nu används och upprepa både det tidigare och det ändrade applikationstestet. Om gatewaytilldelningen har ändrats kontrolleras även backupvägen. Lokala korrigeringar eller borttagningar av Central_-objekt är ingen återställningsväg: den önskade ändringen görs i anslutningsgruppen.

Återställ en utökning eller ta bort gruppen

Om en utökning misslyckas ska inte hela gruppen raderas reflexmässigt. Återställ först endast den nya resursen, brandväggen eller profiländringen i guiden. Vänta tills Sophos Fusion-uppgifterna är klara och kontrollera att tunnlar, routes, regler och det dokumenterade testflödet åter motsvarar utgångsläget. Endast det resultatet bekräftar återställningen; att spara ändringen räcker inte.

Om anslutningsgruppen måste tas bort helt görs detta i ett underhållsfönster. Alternativa vägar mellan platser eller manuellt hanterade tunnlar måste finnas på plats först. Kontrollera efter borttagningen på varje brandvägg att tillhörande Central_-objekt har tagits bort och att inga föräldralösa regler, routes eller NAT-beroenden finns kvar.

Checklista för driftsättning

  • Alla brandväggar kör SFOS 20.0 eller senare, hanteras av Sophos Fusion, är licensierade och tilldelade en brandväggsgrupp; AWS-/Azure-brandväggar använder BYOL.
  • Resurser, tjänster, WAN-vägar och XFRM-nät är dokumenterade och fria från överlappningar.
  • Varje upptäckt konflikt har lösts medvetet.
  • Alla Sophos Fusion-uppgifter har slutförts med ett dokumenterat resultat.
  • Förväntade tunnlar visar GOOD; ett UNKNOWN har utretts och inte räknats som ett godkänt tunneltest.
  • Tunnlar, XFRM-gränssnitt, routes, regler och Central_-objekt har kontrollerats lokalt.
  • Ett verkligt dubbelriktat applikationstest fungerar för varje väg mellan platser.
  • Primär- och backupvägar har testats i ett underhållsfönster.
  • Säkerhetskopia, hanteringsåtkomst och återställningsväg är dokumenterade.

Vanliga frågor

Ersätter en anslutningsgrupp lokal kunskap om IPsec och routing?

Nej. Sophos Fusion automatiserar upprepad konfiguration, men datavägen är fortfarande route-based IPsec med XFRM-gränssnitt, routes, brandväggsregler och eventuellt NAT. Dessa lager måste fortfarande förstås för felsökning och verifiering.

Vad bevisar en grön status i Sophos Fusion?

Grönt betyder att alla brandväggar i gruppen är aktiva. Orange betyder att minst en är inaktiv och rött att alla är inaktiva. Denna tunnelöversikt bevisar inte att varje resurs är nåbar via varje regel och applikation. Lokala kontroller och verkliga testanslutningar behövs fortfarande.

Vad händer när en brandvägg avregistreras?

Sophos Fusion tar bort den tillhörande anslutningsgruppen och de tunnlar som Sophos Fusion har skapat. En brandvägg ska därför inte avregistreras och registreras igen som en rutinmässig felsökningsåtgärd. Ändringen hör hemma i ett underhållsfönster med en säkerhetskopia och en förberedd ersättningsväg.