Két IPsec-átjáró, közös IP nélkül: mit tesz valójában a failover

Ölje meg az A átjárót egy megbeszélés alatt, és figyelje, ahogy az alagút egy perccel később a B-n keresztül visszatér; a kapcsolat működik, a videóhívás talán nem. Ez a hideg failover őszinte formája két, független című IPsec-átjáró között. Az ügyfél újra kiválaszt egy végpontot, és új kapcsolatot épít, ami helyreállítja az elérhetőséget anélkül, hogy átadná a régi munkamenet kriptográfiai állapotát. A sorrend végigkövetése világossá teszi, mely ígéreteket tudja betartani a tervezés.

Állítsuk fel a jelenetet: két cím, nincs lebegő IP

Az A átjáró egy elérhető címen válaszol, a B átjáró pedig egy másikon. Az ügyfélnek van jóváhagyott módja a B kiválasztására, amikor az A eltűnik, és nincs olyan közös külső cím, amelyet mindkét átjáró igényelne. Ebben a tervezésben a virtuális IP pontosan ezt a közös belépési pontot jelenti, nem a távoli hozzáférésű ügyfélnek kiosztott belső címet.

Ez a meghatározás azért számít, mert a két elképzelés összekeveredik a hibajegyekben, és az egyik javítása nem a másik javítása. Az a jelentés, hogy a közös belépés nem követte az átjárót, egy tervezést ír le. Az a jelentés, hogy a laptop elvesztette a belső címét, az ügyfél bérletét írja le. Különböző tulajdonosok, különböző naplók, különböző javítások.

Járjuk végig a hibát: észlelés, majd újraválasztás

Először valami észreveszi, hogy az A nem válaszol többé. Ez lehet halott partner észlelése az alagút rétegén, egy útválasztási protokoll, amely visszavon egy útvonalat, vagy egy alkalmazás időtúllépése, amely végül újracsatlakozásra kényszerít. Mindegyik más időskálán működik, és a leglassabb általában meghatározza, mennyit várnak a felhasználók.

Ezután az ügyfél kiválasztja a B-t azon mechanizmus révén, amelyet a telepítés támogat: egy második beállított távoli végpont, egy egészséges címre feloldott DNS-név, vagy olyan útválasztás, amely most más útvonalat részesít előnyben. A választás szakpolitikai lépés, és a hiba előtt léteznie kell, különben véletlenül történik meg.

Mit örökölhet a B és mit nem

A B megoszthat az A-val egy konfigurációs sablont, egy tanúsító hatóságot és egy hitelesítési szabályzatot. Nem örökölheti az élő biztonsági társításokat. A munkamenet-kulcsok, a biztonsági paraméterindexek és a sorrendállapot ahhoz a kapcsolathoz tartoznak, amelyet az A és az ügyfél létrehozott, és a B-nek ezek egyike sincs meg.

Ennek az állapotnak az átjárók közötti mozgatása valódi mérnöki probléma, ezért a strongSwan magas rendelkezésre állásról szóló dokumentációja klasztertervezésként kezeli, nem konfigurációs kapcsolóként. Egy adott klaszter-recept nem általános válasz egy felhőhálózatra, és a támogató infrastruktúra nélküli másolása bonyolultságot vásárol a folytonosság helyett.

Új kapcsolat létrehozása

A B kiválasztásával az ügyfél új IKE-cserét hajt végre: új nonce-értékek, új Diffie-Hellman-értékek, új azonosítók a létrejövő társításokhoz. A hitelesítés ismét a B-nél történik. Ha a tervezés gépazonosítókon alapul, az újracsatlakozás felügyelet nélkül mehet végbe; ha emberi tényezőt igényel, valakinek jelen kell lennie ahhoz, hogy a failover befejeződjön.

Határozza meg ezt a felhasználói élményt a kiesés előtt, nem alatta. Mondja ki világosan, mit fog tenni az ügyfél, meddig próbálkozik, és mit mutat, amikor feladja, mert az egyperces újracsatlakozás és egy támogatási hívás közötti különbség általában dokumentáció és tesztelt profil.

Ugyanazon belső cím megtartása segít azoknak az alkalmazásoknak, amelyek stabil helyi identitást várnak, és nem tartja meg a munkameneteiket. A NAT-kötések lejárnak, a TCP-kapcsolatok visszaállnak, és bármi, aminek saját időtúllépése van, önállóan dönti el, hogy újra próbálja-e.

Két alagút párhuzamosan más tervezés

Mindkét alagút egyszerre való futtatása érvényes minta, ha mindkét átjáró és az útválasztási tervezés támogatja. Ekkor az útvonalválasztás az aktív útvonalat választja, és a visszaútnak egyeznie kell, különben a forgalom az egyik átjárón távozik és a másikon tér vissza, anélkül hogy állapot párosítaná.

Az átfedő alagútszabályzatok önmagukban nem hoznak létre rendezett failover-t. Két jelöltet hoznak létre, és valaminek determinisztikusan döntenie kell közöttük: legyen az útválasztási metrika, szabályzat-prioritás vagy kifejezett preferencia az ügyfélben.

Bármilyen formát választ, írja le a szerződést: hogyan észleli a hibát, hogyan választja ki az alternatívát, milyen hitelesítést igényel az alternatíva, és mennyi ideig tart várhatóan az újracsatlakozás. A közös IP egyszerűsítheti a felderítést, de nem szinonimája a folyamatos állapotnak, és a rendelkezésre állás így is tervezés.