Drugi wpis VPN sieci WAN zawodzi, a główny nadal działa

Główny tunel pozostaje włączony, użytkownicy pracują dalej, a drugi obwód ISP stoi bezczynnie niezależnie od tego, co zmienisz. Opublikowałeś adres obwodu zapasowego, skierowałeś na niego nazwę, być może dodałeś zapasowy wpis do klienta, a klient albo nigdy go nie próbuje, albo uwierzytelnia się i zaraz potem pada. W przypadkach, które prześledziłem, funkcja przełączania awaryjnego była zwykle w porządku; brakowało jednej z pięciu rzeczy, które czynią wpis użytecznym. Nazwa może się rozwiązywać na adres zapasowy, gdy nic nie nasłuchuje na tym interfejsie, a nasłuch może przyjąć połączenie, gdy odpowiedź wychodzi przez główny. Traktuj każdą sieć WAN jako osobny wpis z własną umową, a awaria przestaje wyglądać na błąd klienta.

Każda sieć WAN potrzebuje własnej umowy wpisu

Zapisz pięć pól dla każdej sieci WAN: publiczną nazwę i adres, transport i port, interfejs lub kontekst, który ją kończy, tożsamość peera, którą ma przedstawiać, oraz miejsce, z którego wychodzi odpowiedź. Dwa obwody to dwa kompletne zestawy. Jeśli drugi zestaw nie ma interfejsu kończącego ani ścieżki powrotnej, nie masz wpisu zapasowego; masz rekord DNS opisujący zamiar.

Urządzenie i jego wersja także muszą obsługiwać taki układ. Rekord DNS nie otworzy usługi na innym interfejsie, a na wielu platformach nasłuch konfiguruje się na adres, a nie na urządzenie. IPsec oparty na interfejsie w ASA wiąże mapy kryptograficzne i grupy tuneli z interfejsem zewnętrznym, więc drugi uplink wymaga polityki tam, gdzie te pakiety faktycznie docierają. Projekty oparte na trasach zachowują się inaczej: nasłuch może wiązać się z każdym adresem albo z jednym nazwanym adresem, a ten wybór decyduje, czy ISP B może w ogóle odpowiedzieć.

Sprawdź, czy druga sieć WAN naprawdę odpowiada

Testuj spoza obu obwodów, nie z maszyny za bramą, i testuj dokładnie tę nazwę, której używa profil klienta. Dla nasłuchu TLS szybkim sprawdzeniem jest openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts uruchomione z hosta poza twoją siecią. Chcesz ukończonego uzgadniania, którego łańcuch zgadza się z nazwą w profilu, a nie tylko portu TCP przyjmującego połączenie.

RFC 9525 wyjaśnia, co sprawdza klient: tożsamość, do której zamierzał dotrzeć, porównaną z certyfikatem przedstawianym przez usługę. Drugi wpis, który zwraca certyfikat wpisu głównego, albo certyfikat domyślny, który nie wymienia żadnej z nazw, nie przechodzi tego testu, mimo że port jest otwarty i zapora go przepuszcza.

Dwa wzorce wyjaśniają większość awarii w tym miejscu. Połączenie, które wisi, zwykle oznacza brak nasłuchu na tym interfejsie, regułę dostępu przepuszczającą tylko główne podsieci albo urządzenie operatora przed drugim obwodem, które porzuca port. Uzgadnianie kończące się niewłaściwą tożsamością zwykle oznacza inny trustpoint, domyślny host wirtualny albo konfigurację skopiowaną z głównego bez dostosowania tożsamości.

Śledź odpowiedź, nie tylko żądanie

Druga sieć WAN zwykle psuje się w drodze powrotnej. Żądanie przychodzi przez ISP B, urządzenie odpowiada, a odpowiedź wychodzi domyślną trasą przez ISP A z adresem źródłowym, o który klient nigdy nie prosił. Tłumaczenie stanowe pogarsza sprawę: jeśli mapowanie zbudowano dla interfejsu głównego, pakiet powrotny mija tłumaczenie albo niesie źródło, które zapora klienta odrzuca. Dostawcy odrzucają też adresy źródłowe nienależące do obwodu, który ci przekazali, i dlatego wygląda to na jednokierunkową czarną dziurę, a nie czysty błąd protokołu.

Sprawdź decyzję routingu dla ruchu pochodzącego z drugiego wpisu. Odpowiedź powinna wyjść interfejsem, którym przyszło żądanie, albo przynajmniej nieść adres, który druga strona akceptuje jako należący do tej ścieżki. Na platformach z routingiem polityki oznacza to regułę powiązaną z interfejsem wejściowym lub tłumaczonym źródłem oraz instrukcję tłumaczenia przypisaną do każdego interfejsu zewnętrznego. Przechwytuj jednocześnie na obu interfejsach, gdy klient się łączy; SYN przychodzący przez ISP B i SYN-ACK wychodzący przez ISP A rozstrzygają sprawę w jednym przebiegu.

Daj klientowi sposób na poznanie drugiego wpisu

Przełączanie awaryjne to decyzja po stronie klienta, a każda rodzina klientów poznaje alternatywy inaczej. W ASA lista serwerów zapasowych jest dostarczana przez atrybuty webvpn polityki grupowej, a inne klienty oczekują listy w profilu albo ręcznego drugiego profilu wybieranego przez użytkownika. Przewodnik Cisco po politykach połączeń opisuje zarówno informacje zapasowe konfigurowane w kliencie, jak i dostarczane przez bramę, a tych szczegółów właściwych protokołowi nie należy uogólniać na każdego klienta ani każdy tryb tunelu. Potwierdź, który mechanizm implementuje wdrożony klient, zanim zbudujesz drugi wpis wokół niewłaściwego.

Nie ma znaczenia mechanizm: klient musi potrafić rozwiązać nazwę alternatywną, zanim utraci główną ścieżkę. To jest zależność, którą ludzie pomijają: jeśli nazwę zapasową odpowiada resolver osiągalny tylko przez tunel, który właśnie zawiódł, przełączenie nie może nawet wystartować. Opublikuj drugą nazwę w resolverze, który odpowiada lokalnie lub przez internet. Spodziewaj się nowego uwierzytelnienia i nowej sesji aplikacji po przesiadce, bo przełączanie po stronie klienta nie jest przełączaniem stanowym i długotrwałe sesje tego nie przetrwają.

Jeden adres u dwóch dostawców to inny produkt

Utrzymanie jednego publicznego adresu osiągalnego przez oba obwody to usługa routingowa, a nie pole wyboru w VPN. Wymaga przestrzeni adresowej, którą obaj dostawcy zechcą przenosić, ogłoszonej tak, by ich sieci ją akceptowały, i to właśnie daje multihoming z przestrzenią niezależną od dostawcy oraz BGP. Przypisanie adresu ISP A interfejsowi ISP B tam nie prowadzi; pakiet trafia do sieci, która nigdy nie ogłaszała tego prefiksu, i jest odrzucany wyżej.

Nic z tego nie jest potrzebne, by opublikować dwa wpisy. Jeśli klient potrafi trzymać dwie nazwy i przełączać się między nimi, dwa niezależne wpisy wystarczą, a ty unikasz numeru AS, uzgodnień peeringowych i prefiksu, który musi być akceptowany wszędzie. Rozważ opcję przenośnego adresu tylko wtedy, gdy naprawdę potrzebujesz jednego stabilnego punktu wejścia, którego klienty nie da się przestawić na inny, albo gdy przełączanie oparte na DNS z opóźnieniem TTL jest zbyt wolne dla awarii, na którą projektujesz.

Co sprawdzić dalej

Pracuj na zewnątrz od zawodzącego wpisu w tej kolejności: czy drugi adres odpowiada z zewnątrz, czy przedstawia tożsamość oczekiwaną przez klienta, czy odpowiedź wychodzi tą drogą, którą przyszło żądanie, i czy klient może poznać nazwę, zanim jej potrzebuje. Gdzie odpowiedź brzmi nie, napraw tę warstwę i przetestuj ponownie z wdrożonym profilem, a nie z hostem testowym, bo uzgadnianie z laboratorium dowodzi mniej niż ukończone połączenie prawdziwego klienta.

Prowadź krótki rejestr dla każdej sieci WAN z adresem, portem, interfejsem kończącym, nazwą certyfikatu, ścieżką powrotną i regułą tłumaczenia, i sprawdzaj go ponownie przy każdej zmianie obwodu, urządzenia NAT lub wersji klienta. Bezużyteczne ścieżki zapasowe gniją po cichu: nic nie alarmuje o wpisie, którego nikt nie używa, aż do dnia, w którym wszyscy na nim polegają.