സജീവ FTD സൈറ്റ് VPN-കൾ എണ്ണുന്നത്: ഏത് സംഖ്യയാണ് ഉദ്ദേശിക്കുന്നത്?

Ansible ടാസ്ക് എഴുതുന്നതിന് മുൻപ് ഒരു ചെറിയ ചോദ്യത്തിന് ഉത്തരം നൽകുക: എന്താണ് എണ്ണുന്നത്? കോൺഫിഗർ ചെയ്ത പിയർ, ഒരു IKE സെഷൻ, ഒരു IPsec സുരക്ഷാ അസോസിയേഷൻ, നിരീക്ഷിക്കുന്ന ടണൽ സ്ഥിതി രേഖ എന്നിവ നാല് വ്യത്യസ്ത യൂണിറ്റുകളാണ്, കൂടാതെ കീ പുനർനിർമ്മാണമോ ഒന്നിലധികം സംരക്ഷിത നെറ്റ്വർക്കുകളോ അവയുടെ ആകെത്തുക വേർതിരിക്കുന്നു. ഡാഷ്ബോർഡും playbook-ഉം യോജിക്കുന്നില്ലെങ്കിൽ, സാധാരണയായി അവ വ്യത്യസ്ത കാര്യങ്ങളാണ് എണ്ണുന്നത്, അവയിലൊന്ന് തെറ്റാണെന്നല്ല.

ആളുകൾ സജീവം എന്ന് വിളിക്കുന്ന നാല് കാര്യങ്ങൾ

കോൺഫിഗർ ചെയ്ത പിയർ ഒരു ടോപ്പോളജി ഒബ്ജക്റ്റാണ്: ആരോ അത് നിർവചിച്ചതിനാൽ അത് നിലനിൽക്കുന്നു. IKE സെഷൻ നിയന്ത്രണ തലത്തിലെ ബന്ധമാണ്, ട്രാഫിക് ഒഴുകാതെയും അത് മുകളിലായിരിക്കാം. IPsec SA എന്നത് ഒരു നിർദ്ദിഷ്ട സെലക്ടർ ജോടിക്കുള്ള ഡാറ്റ തല അസോസിയേഷനാണ്, ഒരു ടണലിന് പലതും വഹിക്കാം. നിരീക്ഷിക്കുന്ന ടണൽ സ്ഥിതി പ്ലാറ്റ്ഫോമിന്റെ സ്വന്തം പ്രവർത്തന വിധിയാണ്, സാധാരണയായി “ടണൽ മുകളിലുണ്ട്” എന്ന് ഓപ്പറേറ്റർ പറയുമ്പോൾ ഉദ്ദേശിക്കുന്നതിന് ഏറ്റവും അടുത്തത്.

പ്രവർത്തന എണ്ണത്തിന് യുക്തിസഹമായ അടിസ്ഥാനം അവസാനത്തേത് മാത്രമാണ്. ആദ്യത്തേത് ഒരു കോൺഫിഗറേഷൻ ഇൻവെന്ററിയാണ്, അത് സജീവമെന്ന് റിപ്പോർട്ട് ചെയ്യുന്നത് ചൊവ്വാഴ്ച മുതൽ താഴെയുള്ള പിയറിന് ഡാഷ്ബോർഡ് പച്ച കാണിക്കുന്ന രീതിയാണ്. സംഖ്യയുടെ ഉപഭോക്താവിന് ഏത് യൂണിറ്റ് വേണമെന്ന് തീരുമാനിക്കുക, തുടർന്ന് മെട്രിക്കിന് അതിന്റെ സ്വന്തം പേരിൽ ആ യൂണിറ്റ് ലേബൽ ചെയ്യുക.

ആദ്യ തീരുമാനം: ഏത് മാനേജ്മെന്റ് തല?

ഉപകരണം FDM നിയന്ത്രിക്കുന്നുവെങ്കിൽ, പ്രസക്തമായ ഉപരിതലം FTD REST API ആണ്. FMC നിയന്ത്രിക്കുന്നുവെങ്കിൽ, ആ API പരസ്പരം മാറ്റാവുന്ന പകരമല്ല, ഒബ്ജക്റ്റുകൾ FMC-യുടെ സ്വന്തം API-ക്ക് പിന്നിലാണ്. ഒരു അഭ്യർത്ഥന പോലും എഴുതുന്നതിന് മുൻപ് ഇത് സ്ഥിരീകരിക്കുക, കാരണം തെറ്റായ തല അനുമതി പ്രശ്നം പോലെ തോന്നുന്ന വിശ്വസനീയമായ പിശക് നൽകുന്നു.

ഒരു ഫ്ലീറ്റിന്, എണ്ണം എവിടെയാണ് ഉൾപ്പെടുന്നതെന്നും ഉത്തരം തീരുമാനിക്കുന്നു: FDM വഴി ഓരോ ഉപകരണത്തിനും, അല്ലെങ്കിൽ FMC വഴി ഓരോ ഡൊമെയ്നിനും. ഇവ വ്യത്യസ്ത പരിധികളാണ്, ഒരേ ഫ്ലീറ്റിന് വ്യത്യസ്ത സംഖ്യകൾ നൽകുന്നു.

രണ്ടാം തീരുമാനം: ഏത് വിഭവമാണ് ഉത്തരം നൽകുന്നത്?

പതിപ്പ്-പരിമിതമായ ഒരു ഉദാഹരണത്തിന്, FMC 7.3 API ഒബ്ജക്റ്റ് റഫറൻസ് health പാതയ്ക്ക് കീഴിലുള്ള GET വിഭവങ്ങൾ രേഖപ്പെടുത്തുന്നു:

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

ടണൽ സ്ഥിതി വിഭവം ഉപകരണ, സ്ഥിതി ഫിൽട്ടറുകൾ പിന്തുണയ്ക്കുന്നു, അവയിൽ TUNNEL_UP ഉൾപ്പെടുന്നു. അത് ആ പതിപ്പിന് പരിശോധിക്കാൻ യഥാർത്ഥ പ്രവർത്തന വിഭവം നൽകുന്നു, ഫീൽഡ് നാമത്തെക്കുറിച്ചുള്ള ഊഹമല്ല.

പാർസർ നടപ്പാക്കുന്നതിന് മുൻപ് വിന്യസിച്ച 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 അല്ല. active എന്ന JSON കീ കണ്ടുപിടിക്കുന്നതിന് പകരം ഇൻസ്റ്റാൾ ചെയ്ത API-ൽ നിന്ന് യഥാർത്ഥ ഫീൽഡ് നാമങ്ങൾ എടുക്കുക.

പ്രധാന നിയമം പരാജയ സ്വഭാവമാണ്: അംഗീകാര പിശക്, പിന്തുണയ്ക്കാത്ത വിഭവം, പഴയ സാമ്പിൾ, അല്ലെങ്കിൽ അപൂർണ്ണ പേജ് സെറ്റ് എന്നിവ unknown അല്ലെങ്കിൽ error നൽകണം, ഒരിക്കലും വിജയകരമായ പൂജ്യം അല്ല. “എനിക്ക് ചോദിക്കാനായില്ല” എന്നർത്ഥമുള്ള പൂജ്യം ഏറ്റവും ചെലവേറിയ തെറ്റാണ്.

പ്ലാറ്റ്ഫോമിന്റെ സ്വന്തം കാഴ്ചയ്ക്കെതിരെ സാധൂകരിക്കുക

ആദ്യ ഫലം അതേ ഉപകരണത്തിനും നിമിഷത്തിനും പതിപ്പിന്റെ VPN നിരീക്ഷണ കാഴ്ചയുമായി താരതമ്യം ചെയ്യുക. അവ വ്യത്യാസപ്പെടുമ്പോൾ, playbook മാറ്റുന്നതിന് മുൻപ് ഓരോന്നും ഏത് യൂണിറ്റ് ഉപയോഗിക്കുന്നു എന്ന് കണ്ടെത്തുക.

ഓരോ റണ്ണിനും രഹസ്യമല്ലാത്ത സാഹചര്യം സൂക്ഷിക്കുക: പരിധി, സമയ മുദ്ര, മെട്രിക്കിന്റെ യൂണിറ്റ്, രേഖകളുടെ എണ്ണം. FMC 7.3 API ഒബ്ജക്റ്റ് റഫറൻസ് മുകളിലെ വിഭവ പാതകളുടെ ഉറവിടമാണ്, നിങ്ങളുടെ സ്വന്തം വിന്യാസത്തിലെ API Explorer ബാക്കിയെല്ലാറ്റിന്റെയും ഉറവിടമാണ്.