Cloud VPN do Cisco ASA: odbudowa po niezgodności propozycji

NEGOTIATION_FAILURE na tunelu Cloud VPN z Cisco ASA po drugiej stronie prawie zawsze oznacza niezgodność propozycji lub selektorów, a pierwszym użytecznym faktem jest to, że żadna edycja tego nie naprawi. Cloud VPN ustala propozycję IKE w chwili tworzenia obiektu tunelu. Nie ma pola do zmiany algorytmu na miejscu, więc naprawa to usunięcie i ponowne utworzenie z zapisanym punktem wyjścia. Potraktuj to jako odbudowę, a praca zmieni się w listę kontrolną zamiast popołudnia domysłów.

Przeczytaj błąd, zanim cokolwiek usuniesz

Błąd negocjacji to problem fazy, a log partnera zwykle nazywa fazę. Błąd fazy 1 oznacza, że strony nie uzgodniły propozycji albo nie potrafiły się wzajemnie uwierzytelnić. Błąd fazy 2 oznacza, że tunel wstał, a chronione selektory się nie zgadzały. To różne naprawy, i warto wyciągnąć linię z logu, zanim ktokolwiek dotknie konfiguracji.

Błąd wyklucza też pewne rzeczy. To nie trasa VPC, nie reguła firewalla na interfejsie tunelu i nie usterka rozwiązywania nazw w sieci. Ściganie ich daje pewne siebie zmiany, które nie mogą zmienić wyniku, i utrudnia przypisanie ostatecznej poprawki.

Zapisz obie konfiguracje, dopóki jeszcze istnieją

Usunięcie tunelu zajmuje pół minuty i niszczy jedyny dowód, jaki miałeś. Wcześniej zapisz selektory lokalny i zdalny, adres partnera, kto ma wspólny sekret oraz crypto map lub profil IKEv2 na ASA. ASA odpowiada na dwa osobne pytania: co jest skonfigurowane i co jest teraz podniesione:

show running-config crypto ikev2
show crypto ikev2 sa
show crypto ipsec sa | include local ident|remote ident|status

Po stronie Google czytaj obiekt tunelu, a nie podsumowanie konsoli, bo adres partnera i pola selektorów to wartości, które musisz odtworzyć dokładnie:

gcloud compute vpn-tunnels describe tunnel-to-asa --region europe-west1 \
  --format="yaml(peerIp,localTrafficSelector,remoteTrafficSelector,ikeVersion,sharedSecret)"

Wpisz te wartości do zgłoszenia przed pierwszym usunięciem. Odbudowa poniżej działa tylko dlatego, że możesz odtworzyć ten sam obiekt z jedną zamierzoną różnicą.

Algorytmy, o których jedna strona odmawia negocjacji

Cloud VPN nie wybiera z zakresu algorytmów IKEv1 jak tradycyjny partner. Oczekiwane ustawienia partnera są stałe: aes-cbc-128 do szyfrowania, sha1-96 do integralności i PRF, grupa Diffie-Hellmana 2, 36,600 sekund dla fazy 1 i 10,800 sekund dla fazy 2. Polityka ASA musi zaoferować dokładnie ten zestaw. Druga propozycja na ASA nie szkodzi, jeśli pasująca też jest na liście.

IKEv2 daje obu stronom więcej miejsca, ale reguły zachowują ten sam kształt: włącz PFS, wybierz grupę DH obsługiwaną przez tunel i trzymaj listę propozycji tak krótką, by niezgodność była oczywista. Partner ASA na Cloud VPN oznacza też routing statyczny, więc chronione prefiksy trzeba zaplanować i wylistować, a nie zostawiać BGP.

Czas życia skopiowany z szablonu innego producenta to typowy błąd w tym miejscu. Google publikuje te wartości jako wymagane ustawienia partnera, więc je ustaw; krótsza wartość nie jest negocjowana w górę do tego, czego chce ASA.

Usuń, utwórz ponownie i wyczyść stary stan

Usuń tunel, nie bramę, i zapisz nazwę, którą Cloud VPN nadaje zamiennikowi, bo nazwy są nadawane, a nie używane ponownie. Utwórz go ponownie z zapisanymi wartościami i tym samym adresem partnera, a potem dodaj pasującą propozycję do listy polityk ASA.

Wyczyść asocjacje bezpieczeństwa po zmianie na ASA i przed odczytaniem wyniku. ASA może nadal oferować nieaktualną politykę, dopóki bieżące SA nie wygaśnie, więc poprawna konfiguracja wygląda na zepsutą przez cały stary czas życia, a obserwator dochodzi do wniosku, że odbudowa się nie udała, gdy jeszcze się nie zaczęła:

clear crypto ikev2 sa
clear crypto ipsec sa

Potwierdź, że faza 1 wstaje, zanim spojrzysz na fazę 2. Dopóki faza 1 jest na dole, propozycja albo klucz wstępnie współdzielony są błędne, a praca nad selektorami tego nie zmieni.

Selektory zwierciadlą, potem decydują liczniki

Faza 2 działa tylko wtedy, gdy oba końce zgadzają się co do chronionych adresów, a zgoda jest lustrzana, a nie wspólna. Lokalny selektor Google musi odpowiadać selektorowi, który ASA nazywa zdalnym, a zdalny selektor Google temu, co ASA nazywa lokalnym. Tunel z 0.0.0.0/0 po jednej stronie i jedną podsiecią po drugiej przechodzi fazę 1, a potem zawodzi w fazie 2 z tym samym głównym błędem. Żadna strona nie może rozszerzyć listy drugiej.

Dla selektorów opartych na politykach wypisz każdą parę prefiksów i trzymaj listę w zgłoszeniu. Podsieć dodana później na miejscu wymaga edycji po obu stronach, bo nowa trasa na ASA nie rozszerza selektora, a wynikiem jest tunel, który jest podniesiony i przepuszcza ruch tylko dla prefiksów istniejących pierwszego dnia.

Zakończ jednym przepływem od hosta do hosta i odczytaj liczniki bajtów po obu stronach. Liczniki rosnące na ASA i stojące w Google zwykle oznaczają, że odpowiedź wychodzi innym interfejsem albo selektor nie obejmuje prefiksu powrotnego. Zapisz algorytmy, czasy życia, selektory i nową nazwę tunelu, bo następna zmiana propozycji powtórzy tę odbudowę, a te wartości zamieniają ją w krótką robotę.