Druhý koncový bod VPN: co pokrývá a co ne

Dva koncové body na papíře vypadají jako redundance. V praxi druhá adresa pomůže jen tehdy, když se k ní klienti dostanou a když se vyhne poruše, na kterou se připravujete. Dva servery za stejným přístupovým připojením, stejným účtem nebo stejnou cílovou sítí selhávají společně. Užitečná otázka je, kterou jedinou poruchu druhý koncový bod odstraní.

Porovnejte, co oba koncové body sdílejí

Než začnete počítat, co duplikují, vypište, co mají oba koncové body společné. Umístění hostingu, účet poskytovatele, upstream tranzit, DNS hosting, zdroj identity a privátní prostředek za tunelem představují buď sdílenou, nebo nezávislou závislost. Dva virtuální stroje v jedné oblasti sdílejí výpadek poskytovatele. Dvě oblasti pod jedním účtem stále sdílejí fakturační vztah a řídicí rovinu, která je vytváří.

Cílová síť si zaslouží stejný přístup. Zdravá záložní brána nemůže obnovit NAS, který je offline, a nedostane se do kancelářské sítě, jejíž přípojka je mimo provoz. Pokud oba koncové body ústí do stejné privátní podsítě, druhý přidává cestu k cíli, který je už jediným bodem selhání.

Identita je závislost, na kterou se zapomíná. Klonování certifikátu a konfigurace na druhý host vytváří dvě místa, odkud lze stejný údaj zkopírovat, a nic neříká o tom, jak se odvolání dostanou na obě.

Rozhodněte, jak se klient přepíná

Druhý koncový bod je užitečný jen tehdy, když o něm klient ví a dokáže ho vybrat bez volání podpoře. Připojovací profily OpenVPN mohou nést několik řádků remote s politikou výběru a většina klientů nabízí alternativní profil v nabídce. Ať je mechanismus jakýkoli, zapište, který vaši uživatelé mají, protože profil, který nenajdou, není přepnutí.

Přečtěte si dokumentaci klienta ke změnám adresy během relace. Některé implementace drží původního partnera po celou dobu tunelu a alternativy používají až při opětovném připojení. Tento rozdíl rozhoduje, zda mrtvý koncový bod způsobí krátké přerušení, nebo relaci, která se už neobnoví. Otestujte cestu opětovného připojení, místo abyste předpokládali, že nastane.

Změněná výstupní adresa také rozbíjí stav aplikace. Přepnutí je obnova, a popisovat ho jako nepřerušenou kontinuitu vytváří očekávání, které transport nesplní.

Otestujte jednu skutečnou poruchu

Vyberte jeden řízený výpadek a proveďte ho od začátku do konce, místo abyste věřili návrhovému dokumentu. Zastavte primární koncový bod a potvrďte, že oprávněný klient dosáhne zamýšlené aplikace přes alternativu, zatímco neoprávnění klienti stále nemohou. Zapište, jak dlouho přepnutí trvalo a co aplikace viděla.

dig +short vpn2.example.net
ip route get 10.20.30.41
journalctl -u openvpn@backup --since '-10 min'

První příkaz potvrdí, že se záložní jméno překládá na něco směrovatelného dřív, než to budete potřebovat, a to je zde nejlevnější test. Druhý ukáže, které rozhraní by jádro použilo pro privátní cíl, jakmile bude alternativa nahoru. Třetí dá klientský log s názvem partnera, ke kterému se skutečně připojil, a to je jediný důkaz, že k přepnutí došlo. Sledujte i chování blokování během mezery, protože politika, která při přepínání uniká provoz, je horší než krátký výpadek.

Pak vraťte původní a potvrďte, zda se klient vrací. Návrat, který se stane náhodou, je chování, které nikdo neplánoval.

Zapište, co druhá adresa přináší

Shrňte pokrytí v jednom odstavci: kterou poruchu druhý koncový bod odstraní, které poruchy sdílí s prvním a na jakých předpokladech přepnutí stojí. Pojmenujte mechanismus na straně klienta i privátní trasy a chování DNS, které musí existovat na obou místech. Veřejný internetový výstup není náhradou privátní brány a dokumentu, který je staví na roveň, bude věřeno. Přidejte test obnovy, který jste provedli, s datem a výsledkem.

Nezávislost na jednom serveru není nezávislost na sdíleném účtu nebo cílové síti. Právě odstavec, který to říká nahlas, brání tomu, aby se druhá adresa interně prodávala jako vysoká dostupnost. Také říká dalšímu operátorovi, co zkontrolovat nejdřív, když dvojice selže společně.