Gör ruttbaserad IPsec redundant med två internetanslutningar

En andra internetanslutning gör inte automatiskt en IPsec-tunnel redundant. Tillförlitlig failover kräver en separat ruttbaserad anslutning för varje länk, ett separat adresserat XFRM-gränssnitt och en övervakad ruttväg. Först då kan Sophos Firewall medvetet växla trafiken från ISP1 till ISP2 och återgå till den föredragna vägen efter återställning.

Den här arbetsgången gäller ruttbaserad Any-to-Any-IPsec mellan två Sophos Firewalls med SFOS 22.0 och följer Sophos design med två internetanslutningar. Policybaserade tunnlar och ruttbaserade tunnlar med specifika Traffic Selectors använder i stället en IPsec-failovergrupp.

⚠️ Den aktuella Sophos-hjälpen motsäger sig själv om två Any-to-Any-anslutningar. Den särskilda dual-ISP-guiden bygger två tunnlar utan Failover Group. De allmänna anvisningarna för IPsec-felsökning säger däremot att flera anslutningar med samma Local och Remote Subnets, inklusive Any-Any, endast fungerar i samma Failover Group. Gruppen ändrar DPD och Failback. Därför läggs inget odokumenterat steg till här: verifiera designen på installerad SFOS 22 Maintenance Release och ta avvikande beteende till Sophos Support före produktionssättning.

Kort arbetsgång

1. Verifiera separat på båda brandväggarna en Any-to-Any-tunnel via ISP1 och en via ISP2.
2. Tilldela en unik överföringsadress till vart och ett av de fyra XFRM-gränssnitten.
3. Skapa på varje brandvägg en Custom Gateway med ett medvetet valt Health Check för båda XFRM-adresserna hos motparten.
4. Lägg till två statiska rutter till samma fjärr-LAN: Primary med lägre och Backup med högre Administrative Distance.
5. Dokumentera den globala Route Precedence och ställ bara in den på static vpn sdwan_policyroute om det passar hela designen.
6. Kontrollera brandväggsregler och returvägar för båda XFRM-vägarna.
7. Avbryt ISP1 kontrollerat, testa verklig applikationstrafik via ISP2 och verifiera därefter Failback till ISP1.

⚠️ Route Precedence gäller för hela brandväggen. En ändring kan även påverka befintliga Static-, VPN- och SD-WAN-vägar. Dokumentera först aktuellt värde och alla överlappande rutter, skapa en konfigurationsbackup och verifiera en oberoende hanteringsväg.

Design och förutsättningar

Förstå failovermodellen

De två IPsec-anslutningarna förblir separata tunnlar. Rutten med lägre Administrative Distance är den föredragna datavägen. Om dess övervakade XFRM-gateway bedöms som onåbar kan rutten via den andra tunneln ta över.

Detta är två separata tillstånd:

• Tunneln är aktiv: IKE och Child SA har upprättats.
• Vägen är användbar: gateway, rutt, brandväggsregel, förväntat NAT-beteende, motpart och returväg fungerar för verklig trafik.

En grön tunnel är därför inte i sig ett bevis på failover. Vanlig WAN-failover räcker inte heller: WAN link manager skapar ingen andra IPsec-anslutning och ingen matchande rutt hos motparten.

Any-to-Any använder ingen extra VPN-failovergrupp. Adresserade XFRM-gränssnitt, gateways och rutter väljer vägen. Konfigurera en Site-to-Site IPsec VPN förklarar den fullständiga grundkonfigurationen för en sådan tunnel.

SFOS 22 tillåter statiska, SD-WAN- eller dynamiska rutter för Any-to-Any-XFRM-gränssnitt. Den särskilda dual-ISP-proceduren använder uttryckligen två statiska rutter. Den här arbetsgången följer den designen; lägg inte till en SD-WAN-rutt till samma mål utan att separat utforma och testa samspelet och prioriteten.

Planera exempeltopologin

Exemplet ansluter ett huvudkontor till ett filialkontor:

• Huvudkontor: 172.16.16.0/24
• Filialkontor: 192.168.10.0/24
• Primary: ISP1
• Backup: ISP2
• XFRM-nät för ISP1: 10.255.1.0/30
• XFRM-nät för ISP2: 10.255.2.0/30

Head office 172.16.16.0/24                 Branch office 192.168.10.0/24

       xfrm-ISP1 10.255.1.1  ⇄  10.255.1.2 xfrm-ISP1     AD 1
Firewall HQ                                                   Firewall BO
       xfrm-ISP2 10.255.2.1  ⇄  10.255.2.2 xfrm-ISP2     AD 2

Adresserna är dokumentationsvärden och ersätts med egna, icke överlappande överföringsnät. Varje XFRM-par behöver ett separat nät. De publika ISP-adresserna, Local och Remote IDs, Profiles och Listening Interfaces måste för varje tunnel stämma med motparten.

Konfigurera tunnlar, gateways och rutter

Förbered två tunnlar

Skapa två anslutningar under Site-to-site VPN > IPsec på varje brandvägg. Båda använder Route-based (Tunnel interface) och Any för Local subnet och Remote subnet. I en vanlig design med huvudkontor och filial använder huvudkontoret Respond only och filialen Initiate the connection.

Den första tunneln använder WAN-gränssnittet för ISP1 och den andra gränssnittet för ISP2. Testa båda anslutningarna separat innan failover konfigureras. Aktivera varje gång endast den avsedda tunneln och testa ett fastställt dataflöde i båda riktningarna.

Expandera på båda brandväggarna under Network > Interfaces det WAN-gränssnitt som används för respektive IPsec-anslutning. De automatiskt skapade XFRM-gränssnitten visas som underordnade gränssnitt under det. På så sätt går det att koppla varje XFRM-gränssnitt till tunneln via ISP1 eller ISP2 innan dess överföringsadress tilldelas.

Tilldela de automatiskt skapade XFRM-gränssnitten följande exempeladresser under Network > Interfaces:

• Huvudkontor: 10.255.1.1/30 för ISP1 och 10.255.2.1/30 för ISP2
• Filialkontor: 10.255.1.2/30 för ISP1 och 10.255.2.2/30 för ISP2

Ändra inte adressen på ett XFRM-gränssnitt så länge andra rutter eller tjänster är beroende av det. Kontrollera Object usage, tunnelstatus och befintliga routingobjekt före varje ändring.

Övervaka XFRM-gateways

Skapa på båda sidor under Routing > Gateways en gateway per tunnel till motpartens XFRM-adress. På huvudkontoret är det 10.255.1.2 och 10.255.2.2; på filialen 10.255.1.1 och 10.255.2.1.

Ange minst Name, Gateway IP och Interface för varje gateway. Gateway IP är motpartens XFRM-adress och Interface motsvarande XFRM. Health check är avstängt som standard och måste aktiveras för vägövervakning. SFOS 22 visar då Interval (standard 60 sekunder), Time-out (2 sekunder), Retries (3) och minst ett Monitoring condition med Protocol, Port för TCP och IP address.

Probe-IP:t måste vara en värd bakom gatewayen. Välj en stabil och tillåten endpoint bakom motparten för att bedöma hela vägen. En ping endast till XFRM-adressen bevisar bara det direkta tunnelsegmentet. Flera villkor kan kombineras med AND eller OR: AND kräver alla svar, medan OR testar uppifrån tills ett mål svarar.

Valet av protokoll, mål och intervall är ett driftbeslut: målet måste svara stabilt, vara tillgängligt under normalt underhåll och ha rätt tillåtelse. Standardvärdena är startvärden, inte en garanterad omkopplingstid. Godkänn ändringen först efter att tiderna för detektering, Failover och Failback har mätts. Skapa och verifiera en Custom Gateway förklarar Health Check, status och stoppvillkor.

Lägg till statiska Primary- och Backup-rutter

Lägg på huvudkontoret under Routing > Static routes till två IPv4-Unicast-rutter till filialnätet 192.168.10.0/24:

• via 10.255.1.2 och ISP1-XFRM med Administrative distance 1
• via 10.255.2.2 och ISP2-XFRM med Administrative distance 2

Skapa spegelvänt på filialen två rutter till huvudkontorsnätet 172.16.16.0/24:

• via 10.255.1.1 och ISP1-XFRM med Administrative distance 1
• via 10.255.2.1 och ISP2-XFRM med Administrative distance 2

Den lägre Administrative Distance vinner så länge tillhörande gateway är tillgänglig. Identiska destinationsnät och olika avstånd bildar därmed Primary och Backup. Detta skiljer sig från ECMP med samma prioritet. Konfigurera och testa en statisk rutt förklarar den allmänna logiken för rutt och returväg.

Den särskilda Sophos-guiden tillskriver designen automatisk Failover och Failback. Den allmänna referensen för statiska rutter bekräftar prioritet genom Administrative Distance, men beskriver inte separat hur ett misslyckat Health Check tar bort rutten från urvalet. Observera därför den aktiva rutten under verifieringen, inte bara gatewaystatus.

Ställ in Route Precedence kontrollerat

Sophos dokumenterar den här designen med Static före VPN och SD-WAN. Dokumentera först befintligt tillstånd i Device Console:

system route_precedence show

Ställ endast in denna ordning på båda brandväggarna om den passar hela routingdesignen:

system route_precedence set static vpn sdwan_policyroute

Kontrollera därefter värdet igen med system route_precedence show. Ändringen är ingen allmän IPsec-lösning. Den påverkar även andra överlappande Static-, VPN- och SD-WAN-rutter. Ändra Route Precedence säkert förklarar den globala effekten och återställningen.

SFOS 22-hjälpen anger den allmänna standardordningen static, sdwan_policyroute, vpn, medan den särskilda guiden kräver static vpn sdwan_policyroute. Återställ därför exakt den ordning som tidigare registrerades med show och tillämpa inte standarden blint.

Stäm av regler, NAT och returväg

Båda brandväggarna behöver lämpliga regler mellan LAN och VPN. Begränsa källor, mål och tjänster till platsnät och applikationer som faktiskt används; låt Log firewall traffic vara aktiverat under införandet.

Normalt routad trafik mellan platser behöver vanligtvis ingen SNAT. Om det redan finns NAT-undantag eller riktade översättningar måste de fungera på samma sätt på båda vägarna. Lägg inte till en bred MASQ-regel som genväg för failover.

Detta skiljer sig från NAT Traversal. Sophos Firewall aktiverar NAT-T automatiskt och använder UDP 4500 när NAT upptäcks; utan NAT använder IKE UDP 500 och ESP IP-protokoll 50. Om en brandvägg finns bakom en överordnad router måste dess DNAT och tillåtelser nå rätt Listening Interface via båda ISP-vägarna. Överlappande platsnät kräver däremot motsvarande SNAT- och DNAT-regler för nyttotrafiken.

Rutten hos motparten är lika viktig som vägen dit. En tunnel kan vara aktiv trots att svaret återvänder via fel ISP eller en mer generell rutt. Utvärdera därför Route Lookup, aktiv rutt, Firewall Rule ID, NAT Rule ID och Packet Capture tillsammans.

Verifiera och hantera failover

Verifiera Failover och Failback

Verifiera före avbrottstestet båda tunnlarna separat med samma applikationsflöde. Håll en kontinuerlig testanslutning synlig och skapa även nya sessioner under testet.

Avbryt under underhållsfönstret endast ISP1-vägen på ett kontrollerat sätt. Inaktivera inte båda WAN-portarna eller båda tunnlarna samtidigt. Verifieringen besvarar fyra frågor:

1. Identifieras ISP1-gatewayen som otillgänglig?
2. Blir rutten med Administrative Distance 2 via ISP2-XFRM aktiv?
3. Når nya anslutningar motparten och återvänder svaren via ISP2?
4. Används rutten med Administrative Distance 1 igen efter att ISP1 har återställts?

I Log Viewer och en snäv Packet Capture måste förväntad Firewall Rule ID, aktivt XFRM-gränssnitt och dubbelriktat dataflöde stämma överens. En ping räcker inte. HTTPS, RDP, VoIP eller en annan verklig applikation visar dessutom om sessionsuppbyggnad, MTU och returväg fungerar. Testa en brandväggsregel med Log Viewer och Packet Capture förklarar den kombinerade arbetsgången.

Testa i ett HA-kluster en ny anslutning via båda ISP-vägarna efter en planerad Failover. SFOS 22 återställer ruttbaserade IPsec-tunnlar sömlöst, men begränsar sessions-Failover för trafik i tunneln till tillståndslösa protokoll som UDP och ICMP; TCP stöds inte. Bedöm en befintlig och en ny TCP-anslutning separat. HA-loggar och -rapporter finns dessutom bara på noden som behandlade trafiken; kontrollera båda enheterna.

Avgränsa fel systematiskt

Båda tunnlarna är gröna, men ISP2 tar inte över

Kontrollera gatewaystatus, Monitoring Target och båda de statiska rutterna. Destinationsnät och prefix måste vara identiska, medan Next Hops och XFRM-gränssnitt måste skilja sig. Jämför sedan Administrative Distance och aktuell Route Precedence.

ISP2 tar över, men applikationerna svarar inte

Kontrollera brandväggsregler, NAT-undantag och returväg på båda sidor. Packet Capture måste visa request och reply på ISP2-XFRM. Om bara svaret saknas ligger felet vanligtvis bakom motparten eller i en asymmetrisk returväg.

Failback växlar tillbaka för tidigt eller inte alls

Observera Health Check och Monitoring Target. Målet får inte periodvis rapportera tunneln som frisk medan applikationsvägen fortfarande är störd. Kontrollera Administrative Distance, aktiv rutt och en verkligt ny session tillsammans; befintliga anslutningar kan förbli bundna till sitt tidigare tillstånd.

Endast en riktning fungerar

Jämför den spegelvända konfigurationen: XFRM-adress, gateway, statisk rutt, regel och returväg måste finnas på båda brandväggarna. Sophos aktuella felsökning anger /log/strongswan.log, /log/charon.log, /log/strongswan-monitor.log och /log/dgd.log; den sista innehåller händelser för Dead Gateway Detection och VPN Failover. I Advanced Shell visar det skrivskyddade kommandot ip xfrm state om Transform States finns. Felsökning av IPsec VPN förklarar den säkra diagnosen.

Tunnel- och gatewaystatus stämmer inte överens

DPD och Gateway Health Check mäter olika saker. Dead Peer Detection konfigureras under Profiles > IPsec profiles och upptäcker en IKE-motpart som inte svarar efter att Phase 2-tunneln varit inaktiv; Sophos rekommenderar att DPD aktiveras. Custom Gateway-kontrollen testar i stället vald värd bakom XFRM-vägen. Stäng inte av DPD för att dölja ett felaktigt probe-mål. Om Sophos Support kräver en Failover Group på grund av dokumentationskonflikten ovan, tänk på att gruppen stänger av DPD i profilen, sätter Key negotiation tries till 3 och inför separat Automatic failback med högst fem försök. Detta är en annan driftmodell och får inte blandas med arbetsgången utan separat verifiering.

Återställ säkert

Dokumentera före ändringen backup, ursprunglig Route Precedence, tunnelstatus, XFRM-adresser, gateways, regler och rutter. Om den redundanta vägen inte är tillförlitlig:

1. Inaktivera de nya Backup-rutterna.
2. Inaktivera ISP2-gateways och den andra tunneln i stället för att ta bort dem direkt.
3. Återställ ursprunglig Route Precedence på båda brandväggarna.
4. Återställ regler och NAT till dokumenterat föregående tillstånd.
5. Testa ursprunglig ISP1-väg igen med en ny applikationssession.

Ta endast bort XFRM-adresser, gateways eller tunnlar när Object usage inte längre visar beroenden. Backup och återställning av Sophos Firewall förklarar backup- och återställningsprocessen.

FAQ