Două gateway-uri IPsec fără IP comun: ce face de fapt failover-ul

Oprește gateway-ul A în timpul unei ședințe și privește tunelul revenind prin B un minut mai târziu; conexiunea funcționează, apelul video poate nu. Aceasta este forma onestă a failover-ului rece între două gateway-uri IPsec cu adrese independente. Clientul selectează din nou un endpoint și construiește o relație nouă, ceea ce restabilește accesibilitatea fără a transfera starea criptografică a sesiunii vechi. Parcurgerea secvenței face evident ce promisiuni poate ține designul.

Pregătește scena: două adrese, niciun IP flotant

Gateway-ul A răspunde la o adresă accesibilă, iar gateway-ul B la alta. Clientul are o modalitate aprobată de a alege B când A dispare, și nu există o adresă externă comună pe care ambele gateway-uri să o revendice. În acest design, un IP virtual înseamnă exact acel punct de intrare comun, nu adresa internă atribuită unui client de acces la distanță.

Această definiție contează pentru că cele două idei se amestecă în tichete, iar remedierea uneia nu este remedierea celeilalte. Un raport că intrarea comună nu a urmat gateway-ul descrie un design. Un raport că laptopul și-a pierdut adresa internă descrie lease-ul clientului. Proprietari diferiți, jurnale diferite, reparații diferite.

Parcurge defecțiunea: detectează, apoi selectează din nou

Mai întâi ceva observă că A a încetat să răspundă. Poate fi detectarea unui partener mort la nivelul tunelului, un protocol de rutare care retrage o cale, sau un timeout de aplicație care în final forțează o reconectare. Fiecare are o altă scară de timp, iar cel mai lent determină de obicei cât așteaptă utilizatorii.

Apoi clientul selectează B prin mecanismul pe care implementarea îl acceptă: un al doilea remote configurat, un nume DNS rezolvat la o adresă sănătoasă, sau rutare care acum preferă o altă cale. Selecția este un pas de politică și trebuie să existe înainte de defecțiune, altfel se va întâmpla din întâmplare.

Ce poate și ce nu poate moșteni B

B poate împărți cu A un șablon de configurare, o autoritate de certificare și o politică de autentificare. Nu poate moșteni asocierile de securitate active. Cheile de sesiune, indicii parametrilor de securitate și starea secvenței aparțin relației pe care A și clientul au stabilit-o, iar B nu are niciuna dintre ele.

Mutarea acelei stări între gateway-uri este o problemă reală de inginerie, de aceea documentația strongSwan privind disponibilitatea ridicată o tratează ca un design de cluster, nu ca un comutator de configurare. O rețetă anume de cluster nu este un răspuns generic pentru o rețea cloud, iar copierea ei fără infrastructura de suport cumpără complexitate în loc de continuitate.

Stabilirea unei relații noi

Cu B selectat, clientul efectuează un schimb IKE nou: valori nonce noi, valori Diffie-Hellman noi, identificatori noi pentru asocierile rezultate. Autentificarea are loc din nou la B. Dacă designul se bazează pe acreditările mașinii, reconectarea poate fi nesupravegheată; dacă necesită un factor uman, cineva trebuie să fie prezent pentru ca failover-ul să se încheie.

Definește acea experiență a utilizatorului înainte de întrerupere, nu în timpul ei. Spune clar ce va face clientul, cât timp va încerca și ce va afișa când renunță, pentru că diferența dintre un minut de reconectare și un apel la suport este de obicei documentație și un profil testat.

Păstrarea aceleiași adrese interne ajută aplicațiile care așteaptă o identitate locală stabilă și nu le păstrează sesiunile. Legăturile NAT expiră, conexiunile TCP sunt resetate, iar orice lucru cu propriul timeout decide independent dacă reîncearcă.

Două tuneluri în paralel sunt un design diferit

Rularea ambelor tuneluri simultan este un model valid când ambele gateway-uri și designul de rutare îl acceptă. Selecția rutei alege atunci calea activă, iar calea de retur trebuie să fie de acord, altfel traficul iese prin un gateway și se întoarce prin celălalt fără stare care să îl potrivească.

Politicile de tunel suprapuse nu creează de la sine un failover ordonat. Ele creează doi candidați, iar ceva trebuie să decidă între ei în mod determinist, fie că este o metrică de rutare, o prioritate de politică sau o preferință explicită în client.

Orice formă ai alege, scrie contractul: cum este detectată defecțiunea, cum este selectat alternativul, ce autentificare necesită și cât timp se așteaptă să dureze reconectarea. Un IP comun poate simplifica descoperirea, dar nu este un sinonim pentru stare continuă, iar disponibilitatea este un design în orice caz.