Cisco ASA do Azure VPN: pary prefiksów selektora ruchu

Tunel wstaje, IKE wygląda zdrowo, a nic przez niego nie przechodzi. To typowy kształt problemu selektora ASA–Azure, dlatego kontrakt piszę, zanim dotknę którejkolwiek konsoli. Kontrakt to cztery rzeczy: obiekty identyfikujące każdego peera, model połączenia, dokładne pary prefiksów i weryfikacja, która dowodzi każdej pary. Pomyl je, a każde późniejsze polecenie będzie debugować konfigurację, której nie powinieneś był budować. Ten runbook to kolejność, której używam, wraz z poleceniami pokazującymi, który obiekt naprawdę jest błędny.

Zapisz cztery obiekty, zanim zaczniesz konfigurować

Zacznij od wydania i platformy ASA, publicznego endpointu, typu i SKU bramy Azure VPN oraz bramy sieci lokalnej reprezentującej twoją stronę. Te cztery nazwy to słownik wszystkiego, co dalej, a każda ma innego właściciela, gdy coś się psuje.

Jeśli dwa z nich wciąż są domysłami, zatrzymaj się. Błędna lista prefiksów w bramie sieci lokalnej nie jest problemem strojenia.

Wybierz jeden model połączenia i przestań mieszać szablony

Projekt crypto map i projekt tunnel interface to różne konfiguracje, a szablon jednego nie staje się ważny dla drugiego przez zmianę adresu peera. Zanotuj, który budujesz, zanim cokolwiek wkleisz, bo niezgodność ujawnia się później jako problem selektora, a nie błąd konfiguracji. Przewodnik interoperacyjności ASA Microsoftu obejmuje oba wzorce i mówi, jaki model bramy Azure zakłada każdy z nich. Jeśli twoje notatki nie nazywają modelu, wciąż nie masz projektu.

Brama Azure oparta na trasach z selektorami ruchu opartymi na politykach to konkretna udokumentowana opcja, a nie domyślna. Jeśli twój projekt od niej zależy, projekt musi to powiedzieć, bo domyślny model selektora opartego na trasach zachowuje się inaczej po stronie Azure.

Limity wersji też należą do kontraktu. Stary raport z pola o limicie domen szyfrowania to punkt danych o konkretnych wydaniach, a nie trwała właściwość każdej ASA.

Wylicz pary prefiksów, nie agregaty

Napisz macierz. Z lokalnych A i B do Azure X i Y to cztery pary, a każda potrzebuje pokrycia albo jawnego wykluczenia. Złączenie A i B w jeden agregat obejmuje też wszystko, co leży między nimi, i tak projekt po cichu powiększa dziurę.

Sprawdź, co wynegocjowały peery, a nie co zapisałeś. Lista sieci lokalnych i zdalnych na ASA to intencja; CHILD SA to wynik.

Gdy brakuje pary, poprawką jest zwykle wiersz access-list albo wpis selektora, a nie nowy tunel.

Weryfikuj poleceniami, które nazywają obiekt

Na ASA potwierdź sesję IKE, potem SA IPsec, potem pary selektora. Każde polecenie odpowiada na inne pytanie, a uruchomienie tylko pierwszego sprawia, że „tunel jest podniesiony” staje się fałszywym wnioskiem. Czytaj dane wyjściowe dla peera, którego naprawdę skonfigurowałeś, a nie dla SA, który akurat jest pierwszy na liście. Strona Azure odpowiada na te same trzy pytania ze swojego punktu widzenia.

show crypto ikev2 sa detailed
show crypto ipsec sa peer 203.0.113.10
show run access-list AZURE-SELECTORS
packet-tracer input inside icmp 10.1.10.10 8 0 10.2.20.20 detailed

Potem zapytaj Azure o stan połączenia przez az network vpn-connection show --name <connection> --query connectionStatus. Połączono z zerem bajtów w ścieżce danych to problem selektora, a nie routingu.

Przetestuj jeden dozwolony przepływ na parę, sprawdź adres źródłowy widziany po drugiej stronie i wypróbuj jeden zasób, który powinien zostać odrzucony. Tylko ten ostatni test dowodzi, że granica nadal istnieje.

Trzymaj zakres szyfrowania osobno od uprawnień dostępu

Szeroki selektor nie jest uprawnieniem. Jeśli obsługiwany układ jest szerszy niż polityka aplikacji, trzymaj wąskie usługi w regułach firewalla, a zakres szyfrowania zostaw tam, gdzie musi być.

Trasy obciążeń Azure i lokalne trasy powrotne są przeglądane osobno. Ogłoszenia BGP, statyczny zakres sieci i trasy definiowane przez użytkownika muszą opisywać tę samą ścieżkę i żadna z nich nie może rekurencyjnie przechwycić transportu peera.

Wycofanie i dowód, że zadziałało

Zachowaj poprzednią działającą konfigurację, zanim zmienisz selektory, i znaj jedno polecenie, które ją przywraca. Na ASA oznacza to zapisaną kopię i pasującą ścieżkę przywracania, a nie pamięć tego, co edytowałeś. Zapisz polecenie przywracania w zgłoszeniu zmian, dopóki zmiana jest jeszcze hipotetyczna. Potem uruchom ponownie te same trzy kontrole: stan IKE, pary SA IPsec, jeden dozwolony przepływ na parę.

Jeśli para nadal zawodzi po przywróceniu, zmiana nie była przyczyną, i właśnie oszczędziłeś sobie drugiej awarii.