Compter les VPN de site FTD actifs : de quel nombre parlez-vous ?

Avant d’écrire la tâche Ansible, répondez à une question plus petite : qu’est-ce qui est compté ? Un pair configuré, une session IKE, une association de sécurité IPsec et un enregistrement d’état de tunnel surveillé sont quatre unités différentes, et le renouvellement des clés ou plusieurs réseaux protégés font diverger leurs totaux. Si le tableau de bord et le playbook ne sont pas d’accord, ils comptent généralement des choses différentes plutôt que l’un des deux se trompe.

Quatre choses que les gens appellent actives

Un pair configuré est un objet de topologie : il existe parce que quelqu’un l’a défini. Une session IKE est une relation du plan de contrôle qui peut être établie alors qu’aucun trafic ne circule. Une SA IPsec est l’association du plan de données pour une paire de sélecteurs donnée, et un tunnel peut en porter plusieurs. Un état de tunnel surveillé est le verdict opérationnel de la plateforme elle-même, généralement ce qui est le plus proche de ce qu’un opérateur entend par le tunnel est établi.

Seul le dernier est une base raisonnable pour un décompte opérationnel. Le premier est un inventaire de configuration, et le signaler comme actif est la façon dont un tableau de bord affiche du vert pour un pair hors service depuis mardi. Décidez de l’unité dont le consommateur du nombre a besoin, puis nommez la métrique avec cette unité dans son propre nom.

Décision un : quel plan de gestion ?

Si l’appareil est géré par FDM, la surface pertinente est l’FTD REST API. S’il est géré par FMC, cette API n’est pas un substitut interchangeable, et les objets vivent derrière l’API propre à FMC. Confirmez-le avant d’écrire une seule requête, car le mauvais plan renvoie une erreur plausible qui ressemble à un problème de permissions.

Pour une flotte, la réponse décide aussi où le décompte appartient : par appareil via FDM, ou par domaine via FMC. Ce sont des portées différentes et elles produisent des nombres différents pour la même flotte.

Décision deux : quelle ressource répond ?

Pour un exemple limité à la version, la référence d’objets de l’FMC 7.3 API documente des ressources GET sous le chemin health :

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

La ressource d’état de tunnel prend en charge les filtres d’appareil et d’état, notamment TUNNEL_UP. Cela vous donne une ressource opérationnelle réelle à inspecter pour cette version, plutôt qu’une supposition sur un nom de champ.

Confirmez la disponibilité, les permissions, les paramètres de requête et le schéma de réponse dans l’API Explorer du FMC déployé avant d’implémenter un analyseur. La documentation d’une version est un point de départ, pas un contrat pour celle que vous exécutez.

Écrivez le contrat de décompte

Énoncez la métrique en une phrase : enregistrements de tunnel opérationnels uniques pour un appareil et un domaine prévus dont l’état déclaré est TUNNEL_UP. Documentez ensuite comment les appareils redondants et les enregistrements multiples pour un site logique sont représentés, car ces deux cas décident si votre nombre correspond à celui de la réunion.

Ne changez pas silencieusement l’unité d’enregistrement de tunnel à site distant. Si l’entreprise veut des sites, associez explicitement les enregistrements aux sites et publiez la correspondance. Un décompte qui se redéfinit discrètement est pire qu’aucun décompte, car personne ne peut dire quand il a changé.

Traitez la ressource de synthèse comme une commodité seulement après avoir confirmé ce qu’elle synthétise. Elle peut agréger exactement ce dont vous avez besoin, ou répondre à une question subtilement différente. Lisez son schéma une fois, notez la différence, et utilisez la ressource d’état si la synthèse ne peut pas être expliquée. Une synthèse que vous ne comprenez pas est un nombre que vous ne pouvez pas défendre en revue.

Faites en sorte que le flux de travail préserve l’incertitude

Utilisez l’API HTTPS approuvée, validez le certificat, gardez les jetons hors de la sortie de la tâche et récupérez la portée avec le filtre et la pagination pris en charge par la version. Validez ensuite le schéma avant de calculer quoi que ce soit.

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

C’est du pseudo-code de flux de travail, pas un playbook testé. Prenez les noms de champs réels de l’API installée au lieu d’inventer une clé JSON appelée active.

La règle importante est le comportement en cas d’échec : une erreur d’autorisation, une ressource non prise en charge, un échantillon périmé ou un ensemble de pages incomplet doivent produire unknown ou error, jamais un zéro réussi. Un zéro qui signifie que je n’ai pas pu demander est le type d’erreur le plus coûteux.

Validez par rapport à la propre vue de la plateforme

Comparez le premier résultat avec la vue de supervision VPN de la version pour le même appareil et le même instant. Lorsqu’ils diffèrent, déterminez quelle unité chacun utilise avant de modifier le playbook.

Conservez un contexte non secret pour chaque exécution : portée, horodatage, unité de la métrique et nombre d’enregistrements. La référence d’objets de l’FMC 7.3 API est la source des chemins de ressources ci-dessus, et l’API Explorer de votre propre déploiement est la source de tout le reste.