Automatyzacja resetów tuneli ASA: trzy bramy, zanim to dopuścisz

Traktuj automatyczny reset tunelu jako działanie naprawcze o promieniu rażenia, a nie zaplanowaną huśtawkę nastrojów. Decyzja przed tobą jest węższa, niż sugerują narzędzia: która usterka go uzasadnia, którego peera może dotknąć i co go zatrzyma. Pomyl te trzy rzeczy, a zbudowałeś maszynę do usuwania dowodów. Widziałem, jak jedno z takich urządzeń strzelało co piętnaście minut w zdrowego peera przez większość tygodnia i nikt tego nie zauważył, bo tunel za każdym razem wracał.

Brama pierwsza: udowodnij, że usterka jest w tunelu

Skoreluj świeży stan, zanim cokolwiek zatwierdzisz. show crypto ikev2 sa detailed mówi, czy asocjacja IKEv2 istnieje i jak daleko zaszły negocjacje, a show vpn-sessiondb detail l2l daje widok sesji pasujący do tego samego peera. Następnie show crypto ipsec sa peer 203.0.113.10 pokazuje podrzędne SA, liczniki encaps i decaps oraz używane selektory. Rosnący licznik encaps przy płaskim liczniku decaps to zupełnie inny problem niż brak jakiejkolwiek asocjacji.

Następnie sprawdź, czego odbudowa nie naprawi: brakującej trasy powrotnej, MTU połykającego duże pakiety, polityki odrzucającej port po odszyfrowaniu albo asymetrycznego routingu, który wysyła odpowiedzi wokół urządzenia. Wyczyszczenie SA wobec któregokolwiek z nich daje krótki zielony błysk i jutro ten sam bilet. Każdy z nich wygląda z perspektywy aplikacji jak martwy tunel, dlatego liczniki znaczą więcej niż alarm.

Zrób zrzut stanu przed działaniem. Zapisz peera, identyfikatory asocjacji, liczniki w chwili wyzwolenia i dowody, które je wywołały. Reset wyprzedzający zrzut niszczy najcenniejsze dane, jakie miało zdarzenie.

Brama druga: ogranicz zakres do peera, nigdy do świata

W CLI ASA polecenia clear crypto ikev2 sa peer 203.0.113.10 i clear crypto ipsec sa peer 203.0.113.10 są operacjami celowanymi. Te same polecenia bez argumentu peera czyszczą każdą asocjację w kontekście, co czyni je wariantem pisowni i awarią w skutkach. odnośnik poleceń czyszczących Cisco oddziela te formy od wariantu wyłącznie statystycznego, który zeruje liczniki i niczego nie naprawia. W trybie wielokontekstowym polecenie działa tylko na bieżący kontekst, więc automatyzacja musi też wiedzieć, w którym kontekście jest.

Zweryfikuj peera, zanim polecenie zostanie zbudowane. Pusta lub nierozwiązana zmienna musi głośno oblać zadanie, zamiast zapaść się w czyszczenie wszystkiego, a ta kontrola należy do kodu, który recenzent może przeczytać.

Narysuj promień rażenia uczciwie. Jeden peer może nieść kilka chronionych sieci, tysiące sesji i drugi tunel do zarządzania, więc czyszczenie ograniczone do peera nadal jest zdarzeniem wieloklienckim na koncentratorze. Wykonuj działanie ze ścieżki zarządzania, która nie zależy od resetowanego tunelu. Inaczej automatyzacja nie może zweryfikować własnego wyniku, a następnym krokiem jest człowiek jadący na miejsce.

Brama trzecia: ponowienia, ochłodzenie, zdefiniowany sukces

Daj zadaniu blokadę na peera, okres ochłodzenia i twardy limit prób liczony ze świeżych obserwacji. Bez blokady dwa monitory wyzwolone w tej samej chwili czyszczą tego samego peera, gdy trwa renegocjacja, i każdy uznaje, że drugi zawiódł.

Sukces oznacza, że asocjacja wróciła, a dozwolone obciążenie przechodzi, a nie że polecenie wróciło bez błędu. Sprawdź tym samym testem, który wykrył usterkę, a potem potwierdź, że liczniki podrzędnych SA ruszają się w obu kierunkach. Polecenie kończące się zerem, gdy tunel leży, to awaria monitoringu przebrana za naprawę.

Trzymaj nieznane osobno od nieudanego. Jeśli telemetria jest przestarzała albo ścieżka zarządzania jest nieosiągalna, uczciwym stanem jest nieznany, a budżet ponowień nie powinien tego czytać jako pozwolenia na kolejny strzał.

Gdy pierwsze zatwierdzone przywrócenie nie przywraca usługi, eskaluj ze zrzutem stanu zamiast zapętlać. Zaplanowane resety to najgorsza wersja schematu, bo ukrywają usterkę odświeżania kluczy, trasy lub polityki, a jednocześnie tną zdrowe sesje na timerze.

Własność, wyłącznik i jedna próba

Wskaż właściciela, udokumentuj, jak wyłączyć aplet lub harmonogram jednym krokiem, i wyznacz datę przeglądu. Automatyzacja bez ścieżki wyłączenia staje się stałą infrastrukturą w dniu, w którym jej autor zmienia zespół.

Przećwicz ją w laboratorium lub w oknie serwisowym z celowo zepsutym wyborem peera, żeby przekonać się, czy zadanie zawodzi bezpiecznie. Potem przećwicz ścieżkę sukcesu, bo zadanie działające tylko wtedy, gdy coś jest nie tak, niczego cię nie uczy o jego normalnym zachowaniu.