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. Policybaserade tunnlar och ruttbaserade tunnlar med specifika Traffic Selectors använder i stället en IPsec-failovergrupp.

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 övervakad gateway 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.

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.

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.

Välj motsvarande XFRM som Interface. Om hela den efterföljande vägen ska bedömas bör Monitoring Target vara en stabil och tillåten endpoint bakom motparten. En ping endast till motpartens XFRM-adress bevisar enbart det omedelbara tunnelsegmentet.

Valet av mål är ett driftbeslut: det måste svara stabilt, får inte försvinna under normalt underhåll och behöver rätt tillåtelse. Skapa och verifiera en Custom Gateway förklarar Health Check, status och stoppvillkor i detalj.

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.

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.

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.

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. En aktiv tunnel lovar inte att befintliga TCP-sessioner eller routingtillstånd fortsätter utan avbrott.

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. strongswan.log och xfrmi.log hjälper för IKE- och XFRM-lagren; Felsökning av IPsec VPN förklarar den säkra diagnosen.

Å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