Броене на активните сайтови VPN във FTD: кое число имате предвид?

Преди да напишете задачата за Ansible, отговорете на по-малкия въпрос: какво точно се брои? Конфигуриран партньор, IKE сесия, IPsec асоциация за сигурност и запис за наблюдаван статус на тунел са четири различни единици и преизчисляването на ключове или няколко защитени мрежи карат сумите им да се разминават. Ако таблото и playbook-ът не съвпадат, обикновено те броят различни неща, а не че едно от тях греши.

Четири неща, които хората наричат активни

Конфигурираният партньор е топологичен обект: съществува, защото някой го е дефинирал. IKE сесията е връзка на равнището за управление, която може да е вдигната, докато не тече трафик. IPsec SA е асоциацията на равнището за данни за конкретна двойка селектори и един тунел може да носи няколко. Наблюдаваният статус на тунел е собствената оперативна присъда на платформата и обикновено е най-близкото до това, което операторът има предвид с „тунелът е вдигнат“.

Само последното е разумна основа за оперативно броене. Първото е инвентар на конфигурацията и докладването му като активно е начинът, по който таблото показва зелено за партньор, който не работи от вторник. Решете коя единица е нужна на потребителя на числото, после именувайте метриката с тази единица в самото ѝ име.

Решение първо: кое равнище на управление?

Ако устройството се управлява от FDM, релевантната повърхност е FTD REST API. Ако се управлява от FMC, този API не е взаимозаменяем заместител и обектите живеят зад собствения API на FMC. Потвърдете това, преди да напишете дори една заявка, защото грешното равнище връща правдоподобна грешка, която изглежда като проблем с права.

За флот отговорът решава и къде принадлежи броенето: за устройство през FDM или за домейн през FMC. Това са различни обхвати и дават различни числа за един и същ флот.

Решение второ: кой ресурс отговаря?

За пример, ограничен до версия: справочникът на обектите на FMC 7.3 API документира GET ресурси под пътя health:

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

Ресурсът за статус на тунел поддържа филтри по устройство и статус, включително TUNNEL_UP. Това ви дава реален оперативен ресурс за проверка за тази версия, а не догадка за име на поле.

Потвърдете наличност, права, параметри на заявката и схемата на отговора в API Explorer на внедрения FMC, преди да реализирате парсер. Документацията за една версия е отправна точка, а не договор за тази, която изпълнявате.

Напишете договора за броене

Формулирайте метриката с едно изречение: уникални оперативни записи за тунели за едно предвидено устройство и домейн, чието отчетено състояние е TUNNEL_UP. После документирайте как са представени резервните устройства и множеството записи за един логически сайт, защото тези два случая решават дали вашето число съвпада с това от срещата.

Не сменяйте тихо единицата от запис за тунел на отдалечен сайт. Ако бизнесът иска сайтове, съпоставете записите със сайтове явно и публикувайте съпоставянето. Броене, което тихо се предефинира, е по-лошо от липса на броене, защото никой не може да каже кога се е променило.

Отнасяйте се към обобщения ресурс като към удобство само след като потвърдите какво обобщава. Той може да агрегира точно нужното или да отговаря на фино различен въпрос. Прочетете схемата му веднъж, запишете разликата и използвайте ресурса за статус, ако обобщението не може да бъде обяснено. Обобщение, което не разбирате, е число, което не можете да защитите на преглед.

Накарайте работния поток да запазва несигурността

Използвайте одобрения HTTPS API, валидирайте сертификата, дръжте токените извън изхода на задачата и извличайте обхвата с поддържания от версията филтър и страниране. После валидирайте схемата, преди да изчислите каквото и да е.

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

Това е псевдокод на работен поток, а не тестван playbook. Вземете действителните имена на полета от инсталирания API, вместо да измисляте JSON ключ с име active.

Важното правило е поведението при отказ: грешка в оторизацията, неподдържан ресурс, остаряла извадка или непълен набор от страници трябва да дават unknown или error, никога успешна нула. Нула, която означава „не можах да попитам“, е най-скъпият вид грешка.

Валидирайте спрямо собствения изглед на платформата

Сравнете първия резултат с изгледа за VPN мониторинг на версията за същото устройство и момент. Когато се различават, разберете коя единица използва всеки, преди да променяте playbook-а.

Запазвайте несекретен контекст за всяко изпълнение: обхват, времева марка, единица на метриката и брой записи. Справочникът на обектите на FMC 7.3 API е източникът за пътищата на ресурсите по-горе, а API Explorer на вашето собствено внедряване е източникът за всичко останало.