Přepnutí VPN: když zpáteční cesta zůstane ve starém tunelu

Záložní tunel se zvedne, primární spadne a aplikace stále vyprší časový limit. V obou lokalitách vypadá stav tunelu zdravě, a právě to mate. Přepnutí, které přesune požadavky na zálohu, ale odpovědi nechá na staré cestě, není přepnutí. Návod níže testuje zpáteční cestu, ne jen navázání spojení.

Nejprve zapište trasy na obou koncích; pohled z jedné lokality nemůže ukázat asymetrickou cestu. Je to také krok, který se pod časovým tlakem nejčastěji vynechává.

Před testem zapište trasy obou lokalit

Pro každý chráněný prefix zapište primární trasu, záložní trasu a preferenci, která mezi nimi vybírá. Zahrňte bránu LAN za každým koncovým bodem VPN, protože koncový bod je zřídka posledním skokem.

Statické metriky, sledované trasy a dynamické směrování vyjadřují způsobilost různě. Vězte, které váš návrh používá, a co je potřeba, aby se alternativa stala aktivní. Zapište podmínku vedle trasy, například nižší metriku, dokud test neselže.

Udělejte to v obou lokalitách. Záloha preferovaná na jedné straně a ignorovaná na druhé vytváří přesně tu asymetrii, které se snažíte vyhnout.

Sledujte požadavky a odpovědi v každé fázi

Použijte neškodnou povolenou aplikaci a sledujte tři fáze: normální, selhání primární cesty a obnovu. V každé fázi zapište, který tunel nese požadavek a který odpověď. Dostupná adresa protějšku nedokazuje, že chráněná cesta aplikace funguje. Zachyťte to v obou lokalitách, aby byl jednosměrný tok vidět.

Pokud se požadavky přesunou a odpovědi ne, zkontrolujte trasu vzdálené lokality k prefixu klienta a její preferenci zálohy. To je rozhodnutí o směrování, ne selhání tunelu.

Po testu obnovte původní stav a potvrďte, že primární cesta je opět preferovaná. Obnovená primární cesta, která není preferovaná, je návrh přepnutí, který není dokončen.

Řiďte stav relace při změně brány

Firewally a NAT mohou držet stav spojení na jedné bráně a změna cesty na jinou bránu jej nepřenáší. Některé aplikace se připojí samy; jiné selhávají, dokud se relace neobnoví. Pokud záloha mění veřejný zdroj nebo přeloženou privátní adresu, mohou reagovat i pravidla vzdáleného přístupu. Dokumentujte každé očekávané restartování relace místo slibu přepnutí bez přerušení.

Udržujte stabilní adresování tam, kde to aplikace vyžaduje. Návrh přepnutí, který mění zdrojovou adresu pro každou relaci, je designová volba a měl by být zapsán. Tato volba určuje, jak velký výpadek uživatelé skutečně postřehnou.

Testujte aplikaci, která drží dlouhou relaci, ne jen nový požadavek.

Obnovte primární cestu a zkontrolujte kmitání

Potvrďte, že oznámení tras nebo preference se ustálí bez kmitání. Kmitající primární cesta může být rušivější než jasný výpadek, protože každý přechod resetuje stav.

Udržujte správu brány dostupnou přes obnovovací cestu, aby vás test sám neuzamkl. Zapište fáze, pozorované cesty a dobu obnovy; právě tento záznam dělá další přepnutí předvídatelným. Poznámky strongSwan k předávání jsou užitečné, když jsou koncové body hostitelé Linux.