Två IPsec-gateways utan delad IP: vad failover egentligen gör

Döda gateway A mitt under ett möte och se tunneln komma tillbaka via B en minut senare; anslutningen fungerar, videosamtalet kanske inte. Det är den ärliga formen av kall failover mellan två IPsec-gateways med oberoende adresser. Klienten väljer om en ändpunkt och bygger en ny relation, vilket återställer nåbarheten utan att flytta den gamla sessionens kryptografiska tillstånd. Att gå igenom sekvensen gör det tydligt vilka löften designen kan hålla.

Sätt scenen: två adresser, ingen flytande IP

Gateway A svarar på en nåbar adress och gateway B på en annan. Klienten har ett godkänt sätt att välja B när A är borta, och det finns ingen delad extern adress som båda gatewayerna gör anspråk på. I den här designen betyder en virtuell IP just den delade ingångspunkten, inte den inre adressen som tilldelas en fjärråtkomstklient.

Den definitionen spelar roll eftersom de två idéerna blandas ihop i ärenden, och rättelsen av den ena är inte rättelsen av den andra. En rapport om att den delade ingången inte följde gatewayen beskriver en design. En rapport om att den bärbara datorn förlorade sin inre adress beskriver klientens lease. Olika ägare, olika loggar, olika reparationer.

Gå igenom felet: upptäck, välj sedan om

Först märker något att A slutade svara. Det kan vara upptäckt av död peer på tunnelnivå, ett routingprotokoll som drar tillbaka en väg, eller en applikationstimeout som till slut tvingar en återanslutning. Varje har en annan tidsskala, och den långsammaste avgör oftast hur länge användarna väntar.

Sedan väljer klienten B genom den mekanism som utrullningen stöder: en andra konfigurerad fjärradress, ett DNS-namn som löses till en frisk adress, eller routing som nu föredrar en annan väg. Valet är ett policysteg, och det måste finnas före felet, annars sker det av misstag.

Vad B kan och inte kan ärva

B kan dela en konfigurationsmall, en certifikatmyndighet och en autentiseringspolicy med A. Den kan inte ärva de levande säkerhetsassociationerna. Sessionsnycklar, säkerhetsparameterindex och sekvenstillstånd tillhör relationen som A och klienten etablerade, och B har inget av dem.

Att flytta det tillståndet mellan gatewayer är ett verkligt ingenjörsproblem, och därför behandlar strongSwans dokumentation för hög tillgänglighet det som en klusterdesign och inte som en konfigurationsflagga. Ett visst klusterrecept är inte ett generellt svar för ett molnnätverk, och att kopiera det utan den stödjande infrastrukturen köper komplexitet i stället för kontinuitet.

Etablera en ny relation

Med B vald utför klienten ett nytt IKE-utbyte: nya nonce-värden, nya Diffie-Hellman-värden, nya identifierare för de resulterande associationerna. Autentiseringen sker igen hos B. Om designen bygger på maskinuppgifter kan återanslutningen ske utan övervakning; om den kräver en mänsklig faktor måste någon vara närvarande för att failover ska slutföras.

Definiera den användarupplevelsen före avbrottet, inte under det. Säg tydligt vad klienten kommer att göra, hur länge den försöker och vad den visar när den ger upp, för skillnaden mellan en minuts återanslutning och ett supportsamtal är oftast dokumentation och en testad profil.

Att behålla samma inre adress hjälper applikationer som förväntar sig en stabil lokal identitet, och den bevarar inte deras sessioner. NAT-bindningar löper ut, TCP-anslutningar återställs, och allt med egen timeout bestämmer självständigt om det ska försöka igen.

Två tunnlar parallellt är en annan design

Att köra båda tunnlarna samtidigt är ett giltigt mönster när både gatewayerna och routingdesignen stöder det. Ruttvalet väljer då den aktiva vägen, och returvägen måste stämma, annars lämnar trafiken genom en gateway och kommer tillbaka genom den andra utan tillstånd att matcha den.

Överlappande tunnelpolicyer skapar inte ordnad failover av sig själva. De skapar två kandidater, och något måste avgöra mellan dem deterministiskt, vare sig det är ett routingmått, en policyprioritet eller en uttrycklig preferens i klienten.

Vilken form du än väljer, skriv ner kontraktet: hur felet upptäcks, hur alternativet väljs, vilken autentisering det kräver och hur lång tid återanslutningen förväntas ta. En delad IP kan förenkla upptäckten, men det är inte synonymt med kontinuerligt tillstånd, och tillgänglighet är en design oavsett.