Dwie mapy crypto, jeden przepływ: późniejszy wpis nie jest kopią zapasową

Dodaj drugi wpis mapy crypto dla tej samej pary adresów, skieruj go na innego peera i masz gotowy plan przełączenia awaryjnego. To jest mit, a on trwa, bo wygląda jak każda inna uporządkowana lista, którą skonfigurowałeś. Kolejność w mapie crypto decyduje o tym, który wpis przejmuje nowy przepływ, a nie który wpis przejmuje kontrolę, gdy peer przestaje odpowiadać. Nic na tej liście nie monitoruje drugiego końca, więc drugi wpis po prostu tam siedzi i niczego nie przejmuje.

Mit: kolejność oznacza zapas

Uporządkowana lista z dwoma wpisami i jedną wspólną definicją wydaje się główna i zapasowa. Podobieństwo kończy się na składni. Dokumentacja Cisco dla ASA opisuje mapę crypto jako model polityki, który dopasowuje chroniony ruch i nazywa dla niego układ peerów, a dopasowanie odbywa się wobec wpisu, który pierwszy przejmuje przepływ. Dostępność zdalnego peera nie jest częścią tej oceny.

To, co zbudowałeś, to polityka, do której ten przepływ nigdy nie trafi, plus komentarz w rejestrze zmian twierdzący o nadmiarowości.

Kolejność przejmuje przepływ, i to tylko raz

Każdy wpis zawiera listę kontroli dostępu lub definicję chronionego przepływu, a każdy nowy pakiet wychodzący jest porównywany z tymi definicjami w kolejności. Pierwszy wpis, którego definicja pasuje, jest właścicielem przepływu i jego peera. Drugi wpis z identyczną definicją nigdy nie dostaje szansy, bo pierwszy już pasował; drugi wpis z węższą definicją obsługuje tylko przepływy, których pierwszy nie przejął.

To zachowanie jest przydatne, gdy celowo wycinasz wyjątki z szerokiej polityki, a bezużyteczne jako mechanizm przełączenia awaryjnego. Sprawdź, co faktycznie się stało, za pomocą show crypto map i show crypto ipsec sa peer, a następnie prześledź syntetyczny pakiet po ścieżce, którą uważasz, że obrał. Śledzenie wskaże wpis, który go przejął, i to jest jedyna odpowiedź, która ma znaczenie.

Wybór trasy i własność polityki to osobne decyzje

Tablica routingu odpowiada, dokąd pakiet jest przekazywany. Polityka crypto odpowiada, jaka ochrona i który peer mają zastosowanie do wybranego ruchu. Zduplikowanie pary źródła i celu pod innym peerm zmienia drugą decyzję i pozostawia pierwszą nietkniętą, więc odpowiedzi mogą nadal podążać za starą bramą, podczas gdy pakiet wychodzący bierze nowego peera. Ta asymetria tworzy tunel, który zgłasza, że działa, i niczego nie przepuszcza.

Utrzymuj też wzajemność umowy ze zdalnym końcem: zaakceptowana tożsamość, chronione zakresy adresów, trasę powrotną dla interesujących prefiksów i zgodę na usługę. Alternatywny wybór wyjścia, którego druga strona się nie spodziewa, nie jest alternatywną ścieżką, to połowa jednej.

Czego potrzebuje prawdziwa alternatywna ścieżka

Wybierz mechanizm zaprojektowany do tego zadania: obsługiwaną grupę kandydatów na peerów, trasowany tunel z pływającym statykiem lub sąsiedztwem routingu dynamicznego nad nim, albo dowolny projekt nadmiarowości, który twoja platforma dokumentuje dla tej usługi. Potem zapisz, który komponent wykrywa awarię, a który wybiera alternatywę, bo to dwie różne funkcje i często dwa różne zespoły.

Tłumaczenie adresów może też dać witrynie drugi prezentowany adres, ale jednocześnie zmienia selektory, logowanie i reguły dostępu oparte na źródle. Traktuj to jako wyraźny wymóg, a nie obejście dla dwóch niejednoznacznych wpisów.

Testuj trzy stany, nie jeden

Konfiguracja jest ukończona dopiero wtedy, gdy ma obronną odpowiedź dla normalnej pracy, dla stanu awarii podstawowego i dla powrotu do podstawowego. Przetestuj wszystkie trzy i zapisz, który wpis polityki i który peer obsłużył każdy z nich. Test, który zatrzymuje się po pierwszym stanie, dowodzi, że projekt działa, gdy nic nie jest źle, a to stan, którego nie musiałeś sprawdzać.

Odróżniaj też skonfigurowane nakładanie się od legalnego współistnienia starych i nowych asocjacji podczas odświeżania kluczy. Kilka aktywnych SA to normalne i tymczasowe; dwa wpisy walczące o jeden przepływ są trwałe i niewidoczne.