To IPsec-gateways uden fælles IP: hvad failover egentlig gør

Dræb gateway A under et møde, og se tunnelen komme tilbage gennem B et minut senere; forbindelsen virker, videoopkaldet måske ikke. Det er den ærlige form for koldt failover mellem to IPsec-gateways med uafhængige adresser. Klienten vælger et endepunkt igen og opbygger et nyt forhold, hvilket genskaber nåbarhed uden at overføre den gamle sessions kryptografiske tilstand. At gennemgå forløbet gør det tydeligt, hvilke løfter designet kan holde.

Sæt scenen: to adresser, ingen flydende IP

Gateway A svarer på én tilgængelig adresse, og gateway B på en anden. Klienten har en godkendt måde at vælge B på, når A er væk, og der er ingen fælles ekstern adresse, som begge gateways gør krav på. I dette design betyder en virtuel IP netop det fælles indgangspunkt, ikke den indre adresse, der tildeles en fjernadgangsklient.

Den definition betyder noget, fordi de to idéer bliver blandet sammen i sager, og rettelsen af den ene er ikke rettelsen af den anden. En rapport om, at den fælles indgang ikke fulgte gatewayen, beskriver et design. En rapport om, at den bærbare computer mistede sin indre adresse, beskriver klientens lease. Forskellige ejere, forskellige logfiler, forskellige reparationer.

Gå gennem fejlen: registrér, og vælg så igen

Først bemærker noget, at A holdt op med at svare. Det kan være registrering af død peer på tunnelniveau, en routingprotokol, der trækker en rute tilbage, eller en applikationstimeout, der til sidst tvinger en genopkobling. Hver har en forskellig tidsskala, og den langsomste bestemmer normalt, hvor længe brugerne venter.

Derefter vælger klienten B gennem den mekanisme, som udrulningen understøtter: en anden konfigureret fjernadresse, et DNS-navn, der opløses til en sund adresse, eller routing, der nu foretrækker en anden vej. Valget er et politisk trin, og det skal findes før fejlen, ellers sker det ved et tilfælde.

Hvad B kan og ikke kan arve

B kan dele en konfigurationsskabelon, en certifikatmyndighed og en godkendelsespolitik med A. Den kan ikke arve de levende sikkerhedsassociationer. Sessionsnøgler, sikkerhedsparameterindekser og sekvenstilstand tilhører det forhold, som A og klienten etablerede, og B har ingen af dem.

At flytte den tilstand mellem gateways er et reelt ingeniørproblem, og derfor behandler strongSwans dokumentation for høj tilgængelighed det som et klyngedesign i stedet for et konfigurationsflag. En bestemt klyngeopskrift er ikke et generelt svar for et cloudnetværk, og at kopiere den uden den understøttende infrastruktur køber kompleksitet i stedet for kontinuitet.

Etablering af et nyt forhold

Med B valgt udfører klienten en ny IKE-udveksling: nye nonce-værdier, nye Diffie-Hellman-værdier, nye identifikatorer til de resulterende associationer. Godkendelsen sker igen hos B. Hvis designet bygger på maskinlegitimationsoplysninger, kan genopkoblingen være uden opsyn; hvis det kræver en menneskelig faktor, skal nogen være til stede for, at failoveret kan fuldføres.

Definér den brugeroplevelse før afbrydelsen, ikke under den. Sig klart, hvad klienten vil gøre, hvor længe den vil prøve, og hvad den vil vise, når den giver op, fordi forskellen mellem et minuts genopkobling og en supportopringning normalt er dokumentation og en testet profil.

At bevare den samme indre adresse hjælper applikationer, der forventer en stabil lokal identitet, og det bevarer ikke deres sessioner. NAT-bindinger udløber, TCP-forbindelser nulstilles, og alt med sin egen timeout beslutter selvstændigt, om det skal prøve igen.

To tunneller parallelt er et andet design

At køre begge tunneller samtidig er et gyldigt mønster, når både gatewayerne og routingdesignet understøtter det. Rutevalget vælger så den aktive vej, og returvejen skal stemme overens, ellers forlader trafikken gennem én gateway og kommer tilbage gennem den anden uden tilstand til at matche den.

Overlappende tunnelpolitikker skaber ikke ordentligt failover i sig selv. De skaber to kandidater, og noget skal beslutte mellem dem deterministisk, hvad enten det er en routingmetrik, en politikprioritet eller en eksplicit præference i klienten.

Uanset hvilken form du vælger, så skriv kontrakten ned: hvordan fejlen registreres, hvordan alternativet vælges, hvilken godkendelse alternativet kræver, og hvor lang tid genopkoblingen forventes at tage. En fælles IP kan forenkle opdagelsen, men det er ikke synonymt med vedvarende tilstand, og tilgængelighed er et design uanset hvad.