Նախքան Ansible առաջադրանքը գրելը, պատասխանեք ավելի փոքր հարցի. ի՞նչ է հաշվվում։ Կարգավորված գործընկերը, IKE նստաշրջանը, IPsec անվտանգության ասոցիացիան և հսկվող թունելի կարգավիճակի գրառումը չորս տարբեր միավորներ են, և բանալիների վերագեներացումը կամ մի քանի պաշտպանված ցանցերը ստիպում են դրանց գումարներին տարանջատվել։ Եթե վահանակը և playbook-ը չեն համընկնում, սովորաբար նրանք տարբեր բաներ են հաշվում, այլ ոչ թե նրանցից մեկը սխալ է։

Չորս բան, որ մարդիկ անվանում են ակտիվ

Կարգավորված գործընկերը տոպոլոգիայի օբյեկտ է. այն գոյություն ունի, որովհետև ինչ-որ մեկը սահմանել է այն։ IKE նստաշրջանը կառավարման հարթության հարաբերություն է, որը կարող է վերևում լինել, մինչդեռ տրաֆիկ չի հոսում։ IPsec SA-ն տվյալների հարթության ասոցիացիան է կոնկրետ ընտրիչ զույգի համար, և մեկ թունելը կարող է կրել մի քանիսը։ Հսկվող թունելի կարգավիճակը հարթակի սեփական գործառնական վճիռն է, որը սովորաբար ամենամոտն է այն բանին, ինչ օպերատորը նկատի ունի՝ ասելով, որ թունելը վերևում է։

Միայն վերջինն է գործառնական հաշվարկի ողջամիտ հիմք։ Առաջինը կոնֆիգուրացիայի գույքացուցակ է, և այն ակտիվ համարելը այն եղանակն է, որով վահանակը կանաչ է ցույց տալիս երեքշաբթիից ի վեր անջատված գործընկերոջ համար։ Որոշեք, թե թվի սպառողին որ միավորն է պետք, ապա պիտակավորեք չափիչը այդ միավորով նրա սեփական անվան մեջ։

Առաջին որոշում. ո՞ր կառավարման հարթությունը։

Եթե սարքը կառավարվում է FDM-ով, համապատասխան մակերևույթը FTD REST API-ն է։ Եթե այն կառավարվում է FMC-ով, այդ API-ն փոխարինելի այլընտրանք չէ, և օբյեկտները գտնվում են FMC-ի սեփական API-ի հետևում։ Հաստատեք դա նախքան մեկ հարցում գրելը, որովհետև սխալ հարթությունը վերադարձնում է հավանական սխալ, որը թույլտվության խնդրի տեսք ունի։

Նավատորմի համար պատասխանը նաև որոշում է, թե որտեղ է պատկանում հաշվարկը. յուրաքանչյուր սարքի համար 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 արժեքը։ Դա ձեզ տալիս է իրական գործառնական ռեսուրս՝ այդ տարբերակի համար ստուգելու համար, ոչ թե դաշտի անվան շուրջ ենթադրություն։

Նախքան parser իրականացնելը հաստատեք հասանելիությունը, թույլտվությունները, հարցման պարամետրերը և պատասխանի սխեման տեղակայված FMC-ի API Explorer-ում։ Մեկ տարբերակի փաստաթղթերը մեկնարկային կետ են, ոչ պայմանագիր այն տարբերակի համար, որը դուք գործարկում եք։

Գրեք հաշվարկի պայմանագիրը

Ձևակերպեք չափիչը մեկ նախադասությամբ. եզակի գործառնական թունելի գրառումներ մեկ նախատեսված սարքի և տիրույթի համար, որոնց հաղորդված վիճակը 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-ից, փոխարենը հորինելու active անունով JSON բանալի։

Կարևոր կանոնը ձախողման վարքագիծն է. լիազորման սխալը, չաջակցվող ռեսուրսը, հնացած նմուշը կամ թերի էջերի հավաքածուն պետք է արտադրեն unknown կամ error, երբեք՝ հաջող զրո։ Զրոն, որը նշանակում է՝ չկարողացա հարցնել, սխալի ամենաթանկ տեսակն է։

Ստուգեք հարթակի սեփական տեսքի համեմատ

Համեմատեք առաջին արդյունքը տարբերակի VPN մոնիտորինգի տեսքի հետ նույն սարքի և պահի համար։ Երբ դրանք տարբերվում են, պարզեք, թե յուրաքանչյուրը որ միավորն է օգտագործում, նախքան playbook-ը փոխելը։

Պահեք ոչ գաղտնի համատեքստ յուրաքանչյուր գործարկման համար. ծավալ, ժամանակի դրոշմանիշ, չափիչի միավոր և գրառումների քանակ։ FMC 7.3 API օբյեկտների տեղեկատուն վերևի ռեսուրսային ուղիների աղբյուրն է, իսկ ձեր սեփական տեղակայման API Explorer-ը՝ մնացած ամեն ինչի աղբյուրը։

Առնչվող հոդվածներ