Druhá WAN brána VPN nefunguje, zatímco primární stále běží

Primární tunel zůstává nahoře, uživatelé pracují dál a druhý okruh ISP leží ladem, ať změníte cokoli. Zveřejnili jste adresu pro záložní okruh, namířili na ni jméno, možná přidali záložní záznam do klienta, a klient ho buď nikdy nezkusí, nebo se autentizuje a pak spadne. V případech, které jsem sledoval, byla funkce přepnutí obvykle v pořádku; chyběla jedna z pěti věcí, které dělají záznam použitelným. Jméno se může přeložit na záložní adresu, zatímco na tom rozhraní nic neposlouchá, a listener může přijmout spojení, zatímco odpověď odchází přes primární. Berte každý WAN jako samostatný záznam s vlastní smlouvou a selhání přestane vypadat jako chyba klienta.

Každý WAN potřebuje vlastní smlouvu záznamu

Zaznamenejte pět polí pro každý WAN: veřejné jméno a adresu, transport a port, rozhraní nebo kontext, který ho ukončuje, identitu protějšku, kterou má předložit, a místo, odkud odpověď odchází. Dva okruhy znamenají dvě kompletní sady. Pokud druhá sada nemá ukončující rozhraní nebo zpáteční cestu, nemáte záložní záznam; máte záznam DNS, který popisuje záměr.

Zařízení a jeho verze také musí toto uspořádání podporovat. Záznam DNS nemůže otevřít službu na jiném rozhraní a na mnoha platformách se listener konfiguruje na adresu, nikoli na zařízení. IPsec založený na rozhraní na ASA váže kryptomapy a skupiny tunelů na vnější rozhraní, takže druhý uplink potřebuje politiku tam, kde tyto pakety skutečně dorazí. Návrhy založené na trasách se chovají jinak: listener se může vázat na každou adresu nebo na jednu pojmenovanou adresu, a tato volba rozhoduje, zda ISP B může vůbec odpovědět.

Ověřte, že druhý WAN skutečně odpovídá

Testujte zvenku oba okruhy, ne ze stroje za branou, a testujte přesně to jméno, které používá profil klienta. Pro TLS listener je rychlá kontrola openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts spuštěná z hostitele mimo vaši síť. Chcete dokončený handshake, jehož řetěz odpovídá jménu v profilu, ne jen TCP port, který přijme spojení.

RFC 9525 vysvětluje, co klient kontroluje: identitu, ke které chtěl dojít, ve srovnání s certifikátem, který služba předkládá. Druhý záznam, který vrací certifikát primárního záznamu, nebo výchozí certifikát, který neuvádí ani jedno ze jmen, v tomto testu selže, i když je port otevřený a firewall ho povoluje.

Dva vzorce vysvětlují většinu selhání zde. Spojení, které visí, obvykle znamená žádný listener na tom rozhraní, přístupové pravidlo povolující jen primární podsítě, nebo zařízení operátora před druhým okruhem, které port zahazuje. Handshake, který skončí se špatnou identitou, obvykle znamená jiný trustpoint, výchozí virtuální hostitel nebo konfiguraci zkopírovanou z primárního bez úpravy identity.

Sledujte odpověď, ne jen požadavek

Druhý WAN se obvykle láme na cestě zpět. Požadavek dorazí přes ISP B, zařízení odpoví a odpověď odejde přes výchozí trasu na ISP A se zdrojovou adresou, kterou klient nikdy nežádal. Překlad se stavem to zhoršuje: pokud bylo mapování postaveno pro primární rozhraní, vracející se paket mine překlad nebo nese zdroj, který firewall klienta zahodí. Poskytovatelé také zahazují zdrojové adresy, které nepatří okruhu, jenž vám dali, a proto to vypadá jako jednosměrná černá díra, ne jako čistá chyba protokolu.

Zkontrolujte rozhodnutí směrování pro provoz pocházející z druhého záznamu. Odpověď má odejít rozhraním, kterým požadavek dorazil, nebo alespoň nést adresu, kterou vzdálená strana přijímá jako patřící této cestě. Na platformách se směrováním podle politiky to znamená pravidlo navázané na příchozí rozhraní nebo přeložený zdroj, plus příkaz překladu navázaný na každé vnější rozhraní. Zachytávejte současně na obou rozhraních, zatímco se klient připojuje; SYN přicházející přes ISP B a SYN-ACK odcházející přes ISP A otázku vyřeší na jeden běh.

Dejte klientovi způsob, jak se o druhém záznamu dozvědět

Přepnutí je rozhodnutí na straně klienta a každá rodina klientů se o alternativách dozvídá jinak. Na ASA se seznam záložních serverů doručuje přes atributy webvpn skupinové politiky, zatímco jiní klienti očekávají seznam v profilu nebo ruční druhý profil, který uživatel vybere. Průvodce politikami připojení od Cisco popisuje jak informace konfigurované v klientovi, tak informace poskytnuté branou, a tyto detaily specifické pro protokol se nemají zobecňovat na každého klienta nebo režim tunelu. Potvrďte, který mechanismus nasazený klient implementuje, než druhý záznam postavíte kolem špatného.

Ať je mechanismus jakýkoli, klient musí být schopen přeložit alternativní jméno dřív, než ztratí primární cestu. Právě tuto závislost lidé přehlížejí: pokud záložní jméno odpovídá resolver dostupný jen přes tunel, který právě spadl, záloha ani nemůže začít. Zveřejněte druhé jméno v resolveru, který odpovídá lokálně nebo přes internet. Po přechodu očekávejte novou autentizaci a novou relaci aplikace, protože klientský failover není failover se stavem a dlouhé relace ho nepřežijí.

Jedna adresa u dvou poskytovatelů je jiný produkt

Udržet jednu veřejnou adresu dostupnou přes oba okruhy je směrovací služba, ne zaškrtávací políčko ve VPN. Potřebuje adresní prostor, který jsou oba poskytovatelé ochotni nést, ohlášený tak, aby ho jejich sítě přijaly, a to poskytuje multihoming s prostorem nezávislým na poskytovateli a BGP. Přiřazení adresy ISP A rozhraní ISP B tam nevede; paket dorazí do sítě, která prefix nikdy neohlašovala, a je vyhozen výš.

Nic z toho nepotřebujete, abyste zveřejnili dva záznamy. Pokud klient umí držet dvě jména a přepínat mezi nimi, dva nezávislé záznamy stačí a vyhnete se číslu AS, dohodě o peeringu a prefixu, který musí být přijat všude. Možnost přenosné adresy zvažujte jen tehdy, když skutečně potřebujete jeden stabilní vstupní bod, který klienti nemohou překonfigurovat, nebo když je přepínání založené na DNS se zpožděním TTL příliš pomalé pro výpadek, proti kterému navrhujete.

Co zkontrolovat dál

Postupujte od selhávajícího záznamu ven v tomto pořadí: odpovídá druhá adresa zvenku, předkládá identitu, kterou klient očekává, odchází odpověď cestou, kterou požadavek dorazil, a může se klient naučit jméno dřív, než ho potřebuje. Kde je odpověď ne, opravte tu vrstvu a otestujte znovu s nasazeným profilem, ne s testovacím hostitelem, protože handshake z laboratoře dokazuje méně než dokončené spojení skutečného klienta.

Veďte krátký záznam pro každý WAN s adresou, portem, ukončujícím rozhraním, jménem certifikátu, zpáteční cestou a pravidlem překladu, a znovu ho kontrolujte při každé změně okruhu, zařízení NAT nebo verze klienta. Nečinné záložní cesty tiše hnijí: nic nevaruje před záznamem, který nikdo nepoužívá, až do dne, kdy na něm všichni závisí.