Aktive FTD-Standort-VPNs zählen: Welche Zahl meinen Sie?

Bevor Sie die Ansible-Aufgabe schreiben, beantworten Sie eine kleinere Frage: Was wird gezählt? Ein konfigurierter Peer, eine IKE-Sitzung, eine IPsec-Sicherheitsassoziation und ein überwachter Tunnelstatus-Datensatz sind vier verschiedene Einheiten, und Schlüsselerneuerung oder mehrere geschützte Netze lassen ihre Summen auseinanderlaufen. Wenn Dashboard und Playbook nicht übereinstimmen, zählen sie meist verschiedene Dinge, statt dass eines davon falsch ist.

Vier Dinge, die Leute aktiv nennen

Ein konfigurierter Peer ist ein Topologieobjekt: Er existiert, weil ihn jemand definiert hat. Eine IKE-Sitzung ist eine Beziehung auf der Steuerungsebene, die bestehen kann, während kein Datenverkehr fließt. Eine IPsec-SA ist die Datenebenen-Assoziation für ein bestimmtes Selektorpaar, und ein Tunnel kann mehrere tragen. Ein überwachter Tunnelstatus ist das eigene betriebliche Urteil der Plattform und meist am nächsten an dem, was ein Betreiber meint, wenn er sagt, der Tunnel stehe.

Nur die letzte ist eine vernünftige Grundlage für eine betriebliche Zählung. Die erste ist ein Konfigurationsinventar, und sie als aktiv zu melden, ist der Weg, auf dem ein Dashboard Grün für einen Peer zeigt, der seit Dienstag ausgefallen ist. Entscheiden Sie, welche Einheit der Nutzer der Zahl braucht, und benennen Sie die Metrik dann mit dieser Einheit im eigenen Namen.

Entscheidung eins: welche Managementebene?

Wird das Gerät von FDM verwaltet, ist die FTD REST API die relevante Oberfläche. Wird es von FMC verwaltet, ist diese API kein austauschbarer Ersatz, und die Objekte liegen hinter der eigenen API von FMC. Bestätigen Sie das, bevor Sie eine einzige Anfrage schreiben, denn die falsche Ebene liefert einen plausiblen Fehler, der wie ein Berechtigungsproblem aussieht.

Für eine Flotte entscheidet die Antwort auch, wohin die Zählung gehört: pro Gerät über FDM oder pro Domäne über FMC. Das sind unterschiedliche Bereiche, und sie liefern unterschiedliche Zahlen für dieselbe Flotte.

Entscheidung zwei: welche Ressource antwortet?

Für ein versionsgebundenes Beispiel dokumentiert die FMC 7.3-API-Objektreferenz GET-Ressourcen unter dem health-Pfad:

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

Die Tunnelstatus-Ressource unterstützt Geräte- und Statusfilter, einschließlich TUNNEL_UP. Das gibt Ihnen eine echte betriebliche Ressource für diese Version, statt einer Vermutung über einen Feldnamen.

Bestätigen Sie Verfügbarkeit, Berechtigungen, Anforderungsparameter und Antwort-Schema im API Explorer der eingesetzten FMC, bevor Sie einen Parser implementieren. Die Dokumentation einer Version ist ein Ausgangspunkt, kein Vertrag für die Version, die Sie betreiben.

Schreiben Sie den Zählvertrag

Formulieren Sie die Metrik in einem Satz: eindeutige betriebliche Tunnel-Datensätze für ein vorgesehenes Gerät und eine Domäne, deren gemeldeter Zustand TUNNEL_UP ist. Dokumentieren Sie dann, wie redundante Geräte und mehrere Datensätze für einen logischen Standort dargestellt werden, denn diese beiden Fälle entscheiden, ob Ihre Zahl zur Zahl im Meeting passt.

Ändern Sie die Einheit nicht stillschweigend von Tunnel-Datensatz auf entfernten Standort. Will das Geschäft Standorte, ordnen Sie Datensätze Standorten ausdrücklich zu und veröffentlichen Sie die Zuordnung. Eine Zählung, die sich stillschweigend neu definiert, ist schlimmer als keine Zählung, weil niemand sagen kann, wann sie sich geändert hat.

Behandeln Sie die Zusammenfassungsressource erst dann als Bequemlichkeit, wenn Sie bestätigt haben, was sie zusammenfasst. Sie kann genau das aggregieren, was Sie brauchen, oder eine subtil andere Frage beantworten. Lesen Sie ihr Schema einmal, notieren Sie den Unterschied, und nutzen Sie die Statusressource, wenn die Zusammenfassung nicht erklärbar ist. Eine Zusammenfassung, die Sie nicht verstehen, ist eine Zahl, die Sie in einem Review nicht verteidigen können.

Lassen Sie den Workflow die Unsicherheit bewahren

Nutzen Sie die freigegebene HTTPS API, validieren Sie das Zertifikat, halten Sie Tokens aus der Aufgabenausgabe heraus und holen Sie den Bereich mit dem von der Version unterstützten Filter und Paging. Validieren Sie dann das Schema, bevor Sie irgendetwas berechnen.

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

Das ist Workflow-Pseudocode, kein getestetes Playbook. Nehmen Sie die tatsächlichen Feldnamen aus der installierten API, statt einen JSON-Schlüssel namens active zu erfinden.

Die wichtige Regel ist das Fehlerverhalten: Ein Autorisierungsfehler, eine nicht unterstützte Ressource, eine veraltete Stichprobe oder eine unvollständige Seitensammlung müssen unknown oder error ergeben, niemals eine erfolgreiche Null. Eine Null, die bedeutet, ich konnte nicht fragen, ist die teuerste Art von falsch.

Gegen die eigene Sicht der Plattform validieren

Vergleichen Sie das erste Ergebnis mit der VPN-Überwachungsansicht der Version für dasselbe Gerät und denselben Zeitpunkt. Wenn sie abweichen, finden Sie heraus, welche Einheit jeweils verwendet wird, bevor Sie das Playbook ändern.

Bewahren Sie nicht geheimen Kontext für jeden Lauf auf: Bereich, Zeitstempel, Metrikeinheit und Datensatzanzahl. Die FMC 7.3-API-Objektreferenz ist die Quelle für die obigen Ressourcenpfade, und der API Explorer Ihrer eigenen Bereitstellung ist die Quelle für alles andere.