Migracja VPN z IOS do ASA: tłumacz umowę, nie CLI

Konfiguracja IOS, która trafia jako referencja do migracji na ASA, opisuje umowę owiniętą w składnię jednej platformy. Adresy peerów, tożsamości i chronione zakresy to umowa. Key ring, profil i łańcuch crypto map to sposób, w jaki IOS ją wyraża, podczas gdy ASA wyraża ten sam zamiar przez tunnel groups i ich atrybuty. Kopiowanie drugiej części nigdy nie działa, a skopiowanie tylko pierwszej zostawia robotę w połowie.

Przejdź poniższe pięć kroków po kolei i zatrzymaj się tam, gdzie dwie platformy opisują różne rzeczy, a nie różne słowa.

Krok 1: oddziel umowę od składni

Zapisz przekazanie jako wymagania, na które zgadzają się obaj administratorzy. Cztery wiersze pokrywają prawie całość: gdzie jest peer i która strona inicjuje, jak każda strona dowodzi swojej tożsamości, jaka ochrona jest dopuszczalna i które aplikacje muszą przetrwać tunel. Żaden z tych wierszy nie wymienia polecenia.

Zachowaj oryginalny tekst jako dowód, a nie instrukcję. Linia, która istnieje na jednej platformie, a nie na drugiej, jest różnicą składni, dopóki nie sprawdzisz, czy to samo wymaganie da się spełnić inaczej.

Krok 2: nazwij obiekty na każdej platformie

W IOS XE key ring IKEv2 zasila profil IKEv2, a ten profil jest podłączany przez crypto map lub profil IPsec. Na ASA tunnel group przechowuje connection profile i jego atrybuty IPsec, a crypto map wskazuje na niego, jak opisuje to przewodnik po connection profile . To różne grafy obiektów z różnym dziedziczeniem, dlatego mapowanie linia po linii daje konfigurację, która się parsuje i nie łączy.

Buduj obiekty docelowe z wierszy wymagań, a nie z linii źródłowych. Jeśli wiersze są kompletne, konfiguracja docelowa jest decyzją projektową. Jeśli nie są, żadna ilość tłumaczenia poleceń nie dostarczy brakującego zamiaru.

Krok 3: przenieś tożsamość, nie tylko adresy

Tożsamość to część, która psuje się po cichu. Peer uwierzytelniany po adresie zachowuje się inaczej niż ten uwierzytelniany po temacie certyfikatu lub FQDN, a obie platformy zapisują to oczekiwanie w różnych miejscach. Zachowaj zamierzoną tożsamość i łańcuch zaufania, zamiast podstawiać wspólny sekret, bo łatwiej go przetestować.

Trzymaj współdzielony sekret poza notatkami porównawczymi i zgłoszeniami. Zapisz, kto go posiada i jak przechodzi zatwierdzonym kanałem, i pamiętaj, że symbol zastępczy z przykładu w dokumentacji nie jest poświadczeniem klienta.

Krok 4: uzgodnij ochronę przed przełączeniem

Nie przenoś starych ustawień kryptograficznych tylko dlatego, że są w dostarczonym tekście. Uzgodnij część wspólną zestawów szyfrów, które oba wdrożone peery obecnie obsługują, i potwierdź ją z drugim administratorem przed oknem zmian. Jeśli ta część wspólna różni się od oczekiwań istniejącego peera, to zmiana koordynowana, a nie lokalna edycja.

Zapisz uzgodniony zestaw. Dwaj administratorzy z różnymi wspomnieniami rozmowy telefonicznej to właśnie sposób, w jaki przełączenie daje niezgodność fazy drugiej.

Krok 5: weryfikuj usługę, nie składnię

Najpierw sprawdź efektywne obiekty celu, potem zaakceptowane skojarzenie, a następnie rzeczywisty przepływ aplikacji i odpowiedź. Wpisanie polecenia bez błędu dowodzi składni i niczego więcej. Tunel, który wstaje i nie przenosi ruchu, zwykle oznacza, że chronione zakresy lub trasa powrotna nie zgadzają się z drugą stroną, co jest problemem wiersza wymagań, a nie polecenia. Porównaj chronione zakresy po obu stronach, zanim ponownie dotkniesz crypto map.

Zapisz, co zweryfikowałeś, z jakimi adresami i z której strony. Ten zapis zamienia niejednoznaczne twierdzenie, że VPN działa, w coś, co drugi administrator może sprawdzić niezależnie.

Co oddać

Wyślij macierz wymagań, podsumowanie konfiguracji docelowej i wyniki weryfikacji. Wyraźnie wskaż, których ustawień źródłowych nie przeniesiono i dlaczego. Ta lista jest bardziej użyteczna niż przetłumaczona konfiguracja, bo tam zacznie się następna niezgodność.

Zachowaj też tekst źródłowy przy zgłoszeniu. On dokumentuje, o co proszono, a macierz dokumentuje, co uzgodniono.