Liczenie aktywnych VPN-ów lokacji FTD: którą liczbę masz na myśli?

Zanim napiszesz zadanie Ansible, odpowiedz na mniejsze pytanie: co jest liczone? Skonfigurowany partner, sesja IKE, asocjacja bezpieczeństwa IPsec i rekord monitorowanego stanu tunelu to cztery różne jednostki, a regeneracja kluczy lub wiele chronionych sieci sprawiają, że ich sumy się rozjeżdżają. Jeśli pulpit i playbook się nie zgadzają, zwykle liczą różne rzeczy, a nie że jeden z nich jest błędny.

Cztery rzeczy, które ludzie nazywają aktywnymi

Skonfigurowany partner to obiekt topologii: istnieje, bo ktoś go zdefiniował. Sesja IKE to relacja płaszczyzny sterowania, która może być podniesiona, gdy nie płynie ruch. SA IPsec to asocjacja płaszczyzny danych dla określonej pary selektorów, a jeden tunel może nieść kilka. Monitorowany stan tunelu to własny osąd operacyjny platformy, zwykle najbliższy temu, co operator ma na myśli, mówiąc, że tunel jest podniesiony.

Tylko ostatni jest rozsądną podstawą liczenia operacyjnego. Pierwszy to inwentarz konfiguracji, a raportowanie go jako aktywnego to sposób, w jaki pulpit pokazuje zielony dla partnera, który nie działa od wtorku. Zdecyduj, której jednostki potrzebuje odbiorca liczby, a następnie nazwij metrykę tą jednostką w jej własnej nazwie.

Pierwsza decyzja: która płaszczyzna zarządzania?

Jeśli urządzeniem zarządza FDM, właściwą powierzchnią jest FTD REST API. Jeśli zarządza nim FMC, ten interfejs nie jest wymiennym zamiennikiem, a obiekty żyją za własnym API FMC. Potwierdź to, zanim napiszesz choć jedno żądanie, ponieważ niewłaściwa płaszczyzna zwraca wiarygodny błąd, który wygląda jak problem z uprawnieniami.

Dla floty odpowiedź decyduje też, gdzie należy liczenie: na urządzenie przez FDM lub na domenę przez FMC. To różne zakresy i dają różne liczby dla tej samej floty.

Druga decyzja: który zasób odpowiada?

Dla przykładu związanego z wersją referencja obiektów FMC 7.3 API dokumentuje zasoby GET pod ścieżką health:

/api/fmc_config/v1/domain/{domainUUID}/health/tunnelstatuses
/api/fmc_config/v1/domain/{domainUUID}/health/tunnelsummaries

Zasób stanu tunelu obsługuje filtry urządzenia i stanu, w tym TUNNEL_UP. Daje to realny zasób operacyjny do sprawdzenia w tej wersji, a nie domysł o nazwie pola.

Przed implementacją parsera potwierdź dostępność, uprawnienia, parametry żądania i schemat odpowiedzi w API Explorer wdrożonego FMC. Dokumentacja jednej wersji jest punktem wyjścia, a nie umową dla tej, którą uruchamiasz.

Napisz umowę liczenia

Sformułuj metrykę w jednym zdaniu: unikalne operacyjne rekordy tunelu dla jednego zamierzonego urządzenia i domeny, których zgłoszony stan to TUNNEL_UP. Następnie udokumentuj, jak są reprezentowane nadmiarowe urządzenia i wiele rekordów dla jednej lokacji logicznej, ponieważ te dwa przypadki decydują, czy twoja liczba zgadza się z tą na spotkaniu.

Nie zmieniaj po cichu jednostki z rekordu tunelu na zdalną lokację. Jeśli biznes chce lokacji, jawnie odwzoruj rekordy na lokacje i opublikuj to odwzorowanie. Liczenie, które po cichu redefiniuje samo siebie, jest gorsze niż brak liczenia, bo nikt nie potrafi powiedzieć, kiedy się zmieniło.

Traktuj zasób podsumowania jako udogodnienie dopiero po potwierdzeniu, co podsumowuje. Może agregować dokładnie to, czego potrzebujesz, albo odpowiadać na subtelnie inne pytanie. Przeczytaj jego schemat raz, zanotuj różnicę i użyj zasobu stanu, jeśli podsumowania nie da się wyjaśnić. Podsumowanie, którego nie rozumiesz, to liczba, której nie obronisz na przeglądzie.

Niech przepływ pracy zachowa niepewność

Użyj zatwierdzonego HTTPS API, zweryfikuj certyfikat, trzymaj tokeny poza wynikiem zadania i pobierz zakres z filtrem i stronicowaniem obsługiwanymi przez wersję. Następnie zweryfikuj schemat, zanim cokolwiek obliczysz.

fetch intended domain/device runtime records
validate response, completeness and freshness
deduplicate by the documented tunnel identity
count records matching the approved up-state definition
report count with scope, timestamp and metric unit

To pseudokod przepływu pracy, a nie przetestowany playbook. Weź rzeczywiste nazwy pól z zainstalowanego API, zamiast wymyślać klucz JSON o nazwie active.

Ważną zasadą jest zachowanie przy błędzie: błąd autoryzacji, nieobsługiwany zasób, nieaktualna próbka lub niekompletny zestaw stron muszą dawać unknown lub error, nigdy udane zero. Zero, które oznacza, że nie mogłem zapytać, to najdroższy rodzaj błędu.

Zweryfikuj wobec własnego widoku platformy

Porównaj pierwszy wynik z widokiem monitorowania VPN tej wersji dla tego samego urządzenia i momentu. Gdy się różnią, ustal, której jednostki używa każdy z nich, zanim zmienisz playbook.

Zachowaj nie-tajny kontekst dla każdego uruchomienia: zakres, znacznik czasu, jednostkę metryki i liczbę rekordów. referencja obiektów FMC 7.3 API jest źródłem powyższych ścieżek zasobów, a API Explorer we własnym wdrożeniu jest źródłem wszystkiego innego.