Dvě brány IPsec bez společné IP: co skutečně dělá převzetí při výpadku

Ukončete bránu A během schůzky a sledujte, jak se tunel o minutu později vrátí přes B; spojení funguje, videohovor možná ne. To je poctivá podoba studeného převzetí mezi dvěma branami IPsec s nezávislými adresami. Klient znovu vybere koncový bod a vytvoří nový vztah, což obnoví dostupnost bez přenosu kryptografického stavu staré relace. Projití sledu ukáže, které sliby design dokáže dodržet.

Nastavme scénu: dvě adresy, žádná plovoucí IP

Brána A odpovídá na jedné dostupné adrese a brána B na jiné. Klient má schválený způsob, jak zvolit B, když A zmizí, a neexistuje společná vnější adresa, kterou by obě brány nárokovaly. V tomto designu virtuální IP znamená tento společný vstupní bod, nikoli vnitřní adresu přidělenou klientovi vzdáleného přístupu.

Tato definice je důležitá, protože se obě představy v tiktech pletou a oprava jedné není opravou druhé. Zpráva, že společný vstup nenásledoval bránu, popisuje jeden design. Zpráva, že notebook ztratil vnitřní adresu, popisuje klientův pronájem. Různí vlastníci, různé logy, různé opravy.

Projděme výpadek: detekce, pak nový výběr

Nejprve si něco všimne, že A přestala odpovídat. Může to být detekce mrtvého partnera na vrstvě tunelu, směrovací protokol, který stahuje cestu, nebo časový limit aplikace, který nakonec vynutí opětovné připojení. Každý má jiné časové měřítko a nejpomalejší obvykle určuje, jak dlouho uživatelé čekají.

Potom klient vybere B prostřednictvím mechanismu, který nasazení podporuje: druhý nakonfigurovaný vzdálený bod, jméno DNS přeložené na zdravou adresu nebo směrování, které nyní upřednostňuje jinou cestu. Výběr je krok politiky a musí existovat před výpadkem, jinak se stane náhodou.

Co B může a co nemůže zdědit

B může s A sdílet šablonu konfigurace, certifikační autoritu a zásady ověřování. Nemůže zdědit živá bezpečnostní přidružení. Klíče relace, indexy bezpečnostních parametrů a stav posloupnosti patří vztahu, který A a klient vytvořili, a B nemá nic z toho.

Přenos tohoto stavu mezi branami je skutečný inženýrský problém, a proto dokumentace strongSwan pro vysokou dostupnost pojímá tuto věc jako clusterový design, nikoli jako konfigurační přepínač. Konkrétní clusterový recept není obecnou odpovědí pro cloudovou síť a jeho kopírování bez podpůrné infrastruktury kupuje složitost místo kontinuity.

Navázání nového vztahu

Po výběru B provede klient novou výměnu IKE: nové hodnoty nonce, nové hodnoty Diffie-Hellman, nové identifikátory výsledných přidružení. Ověření proběhne znovu na B. Pokud se design spoléhá na strojové přihlašovací údaje, může být opětovné připojení bez dozoru; pokud vyžaduje lidský faktor, musí být někdo přítomen, aby se převzetí dokončilo.

Definujte tento uživatelský zážitek před výpadkem, ne během něj. Řekněte jasně, co klient udělá, jak dlouho se bude snažit a co ukáže, když to vzdá, protože rozdíl mezi minutou opětovného připojení a voláním podpory bývá dokumentace a otestovaný profil.

Zachování stejné vnitřní adresy pomáhá aplikacím, které očekávají stabilní místní identitu, ale nezachovává jejich relace. Vazby NAT vyprší, spojení TCP se resetují a cokoli s vlastním časovým limitem se samostatně rozhoduje, zda to zkusit znovu.

Dva tunely paralelně jsou jiný design

Provozovat oba tunely současně je platný vzor, když to podporují obě brány a design směrování. Výběr trasy pak volí aktivní cestu a zpětná cesta musí souhlasit, jinak provoz odchází jednou branou a vrací se druhou bez stavu, který by jej spároval.

Překrývající se tunelové zásady samy o sobě nevytvářejí uspořádané převzetí. Vytvářejí dva kandidáty a něco mezi nimi musí rozhodnout deterministicky, ať už je to směrovací metrika, priorita zásad nebo výslovná preference v klientovi.

Ať zvolíte jakoukoli podobu, sepište smlouvu: jak se výpadek detekuje, jak se vybírá alternativa, jaké ověření alternativa vyžaduje a jak dlouho se očekává opětovné připojení. Sdílená IP může zjednodušit objevování, ale není synonymem nepřetržitého stavu a dostupnost je v každém případě design.