აქტიური 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. აიღეთ რეალური ველების სახელები დაყენებული API-დან, ნაცვლად იმისა, რომ გამოიგონოთ JSON გასაღები სახელად active.

მთავარი წესი წარუმატებლობის ქცევაა: ავტორიზაციის შეცდომამ, მხარდაუჭერელმა რესურსმა, მოძველებულმა ნიმუშმა ან არასრულმა გვერდების ნაკრებმა უნდა წარმოქმნას unknown ან error, არასოდეს წარმატებული ნული. ნული, რომელიც ნიშნავს, რომ ვერ შევძელი კითხვა, შეცდომის ყველაზე ძვირი სახეობაა.

გადაამოწმეთ თავად პლატფორმის ხედის წინააღმდეგ

შეადარეთ პირველი შედეგი ვერსიის VPN მონიტორინგის ხედს იმავე მოწყობილობისა და მომენტისთვის. როცა ისინი განსხვავდებიან, გაარკვიეთ, რომელ ერთეულს იყენებს თითოეული, სანამ playbook-ს შეცვლით.

შეინახეთ არასაიდუმლო კონტექსტი ყოველი გაშვებისთვის: მოცულობა, დროის ნიშანი, მეტრიკის ერთეული და ჩანაწერების რაოდენობა. FMC 7.3 API ობიექტების ცნობარი ზემოაღნიშნული რესურსული ბილიკების წყაროა, ხოლო API Explorer თქვენსავე განლაგებაზე ყველა დანარჩენის წყაროა.