To IPsec-gatewayer uten felles IP: hva failover egentlig gjør

Drep gateway A midt i et møte og se tunnelen komme tilbake gjennom B et minutt senere; forbindelsen virker, videomøtet kanskje ikke. Det er den ærlige formen for kald failover mellom to IPsec-gatewayer med uavhengige adresser. Klienten velger et endepunkt på nytt og bygger en ny relasjon, noe som gjenoppretter nåbarhet uten å overføre den gamle sesjonens kryptografiske tilstand. Å gå gjennom sekvensen gjør det tydelig hvilke løfter designet kan holde.

Sett scenen: to adresser, ingen flytende IP

Gateway A svarer på én tilgjengelig adresse og gateway B på en annen. Klienten har en godkjent måte å velge B på når A er borte, og det finnes ingen felles ekstern adresse som begge gatewayene gjør krav på. I dette designet betyr en virtuell IP nettopp det felles inngangspunktet, ikke den indre adressen som tildeles en fjernklient.

Den definisjonen betyr noe fordi de to ideene blandes sammen i saker, og rettelsen av den ene er ikke rettelsen av den andre. En rapport om at den felles inngangen ikke fulgte gatewayen, beskriver ett design. En rapport om at den bærbare maskinen mistet sin indre adresse, beskriver klientens leie. Ulike eiere, ulike logger, ulike reparasjoner.

Gå gjennom feilen: oppdage, så velge på nytt

Først merker noe at A sluttet å svare. Det kan være oppdagelse av død peer på tunnellaget, en rutingsprotokoll som trekker tilbake en rute, eller en applikasjonstimeout som til slutt tvinger en gjenoppkobling. Hver har en annen tidsskala, og den tregeste bestemmer vanligvis hvor lenge brukerne venter.

Deretter velger klienten B gjennom den mekanismen utrullingen støtter: en annen konfigurert fjernadresse, et DNS-navn som løses til en sunn adresse, eller ruting som nå foretrekker en annen vei. Valget er et policytiltak, og det må finnes før feilen, ellers skjer det ved en tilfeldighet.

Hva B kan og ikke kan arve

B kan dele en konfigurasjonsmal, en sertifikatmyndighet og en autentiseringspolicy med A. Den kan ikke arve de levende sikkerhetsassosiasjonene. Sesjonsnøkler, sikkerhetsparameterindekser og sekvenstilstand tilhører relasjonen som A og klienten etablerte, og B har ingen av dem.

Å flytte den tilstanden mellom gatewayer er et reelt ingeniørproblem, og derfor behandler strongSwans dokumentasjon for høy tilgjengelighet det som et klyngedesign og ikke som et konfigurasjonsflagg. En bestemt klyngeoppskrift er ikke et generelt svar for et skybasert nettverk, og å kopiere den uten den støttende infrastrukturen kjøper kompleksitet i stedet for kontinuitet.

Etablere en ny relasjon

Med B valgt utfører klienten en ny IKE-utveksling: nye nonce-verdier, nye Diffie-Hellman-verdier, nye identifikatorer for assosiasjonene som oppstår. Autentisering skjer igjen hos B. Hvis designet bygger på maskinlegitimasjon, kan gjenoppkoblingen være uten tilsyn; hvis det krever en menneskelig faktor, må noen være til stede for at failoveren skal fullføres.

Definer den brukeropplevelsen før avbruddet, ikke under det. Si klart hva klienten vil gjøre, hvor lenge den vil prøve og hva den vil vise når den gir opp, fordi forskjellen mellom ett minutts gjenoppkobling og en støttesamtale vanligvis er dokumentasjon og en testet profil.

Å beholde samme indre adresse hjelper applikasjoner som forventer en stabil lokal identitet, og den bevarer ikke sesjonene deres. NAT-bindinger utløper, TCP-tilkoblinger nullstilles, og alt med sin egen timeout bestemmer selvstendig om det skal prøve igjen.

To tunneler parallelt er et annet design

Å kjøre begge tunnelene samtidig er et gyldig mønster når både gatewayene og rutingsdesignet støtter det. Rutevalget velger da den aktive veien, og returveien må stemme, ellers forlater trafikken gjennom én gateway og kommer tilbake gjennom den andre uten tilstand til å matche den.

Overlappende tunnelpolicyer skaper ikke ordentlig failover av seg selv. De skaper to kandidater, og noe må avgjøre mellom dem deterministisk, enten det er en rutingsmetrikk, en policyprioritet eller en eksplisitt preferanse i klienten.

Uansett hvilken form du velger, skriv ned kontrakten: hvordan feilen oppdages, hvordan alternativet velges, hvilken autentisering det krever og hvor lang tid gjenoppkoblingen forventes å ta. En felles IP kan forenkle oppdagelsen, men det er ikke synonymt med kontinuerlig tilstand, og tilgjengelighet er et design uansett.