To IPsec-gatewayar utan felles IP: kva failover eigentleg gjer

Drep gateway A midt i eit møte og sjå tunnelen kome tilbake gjennom B eitt minutt seinare; sambandet verkar, videomøtet kanskje ikkje. Det er den ærlege forma for kald failover mellom to IPsec-gatewayar med uavhengige adresser. Klienten vel eit endepunkt på nytt og byggjer ein ny relasjon, noko som gjenopprettar nåbarheit utan å overføre den kryptografiske tilstanden til den gamle økta. Å gå gjennom sekvensen gjer det tydeleg kva løfte designet kan halde.

Set scenen: to adresser, inga flytande IP

Gateway A svarar på éi tilgjengeleg adresse og gateway B på ei anna. Klienten har ein godkjend måte å velje B på når A er borte, og det finst inga felles ekstern adresse som begge gatewayane gjer krav på. I dette designet tyder ei virtuell IP nettopp det felles inngangspunktet, ikkje den indre adressa som blir tildelt ein fjernklient.

Den definisjonen betyr noko fordi dei to ideane blir blanda saman i saker, og rettinga av den eine er ikkje rettinga av den andre. Ein rapport om at den felles inngangen ikkje følgde gatewayen, skildrar eitt design. Ein rapport om at den berbare datamaskinen mista den indre adressa si, skildrar leiga til klienten. Ulike eigarar, ulike loggar, ulike reparasjonar.

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

Først merkar noko at A slutta å svare. Det kan vere oppdaging av daud partnar på tunnellaget, ein rutingsprotokoll som trekkjer tilbake ein rute, eller ein applikasjonstimeout som til slutt tvingar ei gjenoppkopling. Kvar har ein annan tidsskala, og den tregaste avgjer vanlegvis kor lenge brukarane ventar.

Deretter vel klienten B gjennom den mekanismen utrullinga støttar: ein annan konfigurert fjernadresse, eit DNS-namn som blir løyst til ei sunn adresse, eller ruting som no føretrekkjer ein annan veg. Valet er eit policytiltak, og det må finnast før feilen, elles skjer det ved eit tilfelle.

Kva B kan og ikkje kan arve

B kan dele ein konfigurasjonsmal, ein sertifikatstyresmakt og ein autentiseringspolicy med A. Det kan ikkje arve dei levande tryggleiksassosiasjonane. Øktnøklar, tryggleiksparameterindeksar og sekvenstilstand høyrer til relasjonen som A og klienten etablerte, og B har ingen av dei.

Å flytte den tilstanden mellom gatewayar er eit reelt ingeniørproblem, og difor behandlar strongSwan-dokumentasjonen for høg tilgjenge det som eit klyngedesign og ikkje som eit konfigurasjonsflagg. Ei bestemd klyngeoppskrift er ikkje eit generelt svar for eit skynettverk, og å kopiere ho utan den støttande infrastrukturen kjøper kompleksitet i staden for kontinuitet.

Etablere ein ny relasjon

Med B vald utfører klienten ei ny IKE-utveksling: nye nonce-verdiar, nye Diffie-Hellman-verdiar, nye identifikatorar for assosiasjonane som oppstår. Autentisering skjer igjen hos B. Viss designet byggjer på maskinlegitimasjon, kan gjenoppkoplinga vere utan tilsyn; viss det krev ein menneskeleg faktor, må nokon vere til stades for at failoveren skal bli fullført.

Definer den brukaropplevinga før avbrotet, ikkje under det. Sei klart kva klienten vil gjere, kor lenge han vil prøve og kva han vil vise når han gir opp, fordi skilnaden mellom eitt minutts gjenoppkopling og ein støttesamtale vanlegvis er dokumentasjon og ein testa profil.

Å behalde same indre adresse hjelper applikasjonar som ventar ein stabil lokal identitet, og ho bevarer ikkje øktene deira. NAT-bindingar går ut, TCP-tilkoplingar blir nullstilte, og alt med sin eigen timeout avgjer sjølvstendig om det skal prøve igjen.

To tunnelar parallelt er eit anna design

Å køyre begge tunnelane samtidig er eit gyldig mønster når både gatewayane og rutingsdesignet støttar det. Rutevalet vel då den aktive vegen, og returvegen må stemme, elles forlèt trafikken gjennom éin gateway og kjem tilbake gjennom den andre utan tilstand til å matche han.

Overlappande tunnelpolicyar skaper ikkje ordentleg failover av seg sjølv. Dei skaper to kandidatar, og noko må avgjere mellom dei deterministisk, anten det er ein rutingsmetrikk, ein policyprioritet eller ei eksplisitt preferanse i klienten.

Kva form du enn vel, skriv ned kontrakten: korleis feilen blir oppdaga, korleis alternativet blir valt, kva autentisering det krev og kor lang tid gjenoppkoplinga er venta å ta. Eit felles IP kan forenkle oppdaginga, men det er ikkje synonymt med kontinuerleg tilstand, og tilgjenge er eit design uansett.