განსაზღვრეთ VPN ობიექტი SNMP ან API-ის არჩევამდე

ტრანსპორტამდე სამი გადაწყვეტილება დგას: რომელ ობიექტს აღწერს გაფრთხილება, რომელ მიმართულებასა და ფარგლებს ფარავს და რამდენად ახალი უნდა იყოს წაკითხვა. SNMP, HTTPS API და აპლიკაციის ზონდი ყველა შეიძლება რაღაცას აცნობოს VPN-ის შესახებ და ისინი ერთსა და იმავეს არ აცნობებენ. პროტოკოლების შეცვლა ამ სამის გადაწყვეტის გარეშე მხოლოდ იმას ცვლის, სად გროვდება დაბნეულობა. ობიექტი და გაფრთხილების მნიშვნელობა დიზაინია; პროტოკოლი მიწოდებაა.

დაფა, რომელიც ოთხ სხვადასხვა დაკვირვებას ერთ მწვანე ხატულად აქცევს, უკვე ცუდად მიიღო ეს გადაწყვეტილება.

რას უნდა ნიშნავდეს გაფრთხილება სინამდვილეში?

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

დაწერეთ ის წინადადებად, რომლის მიხედვითაც მორიგე ინჟინერს შეუძლია იმოქმედოს. თუ წინადადებას ორი ობიექტი სჭირდება, ეს ორი გაფრთხილებაა და არა ერთი ნახევრად სწორი.

TCP ცხრილი TCP-ს აღწერს

RFC 4022 განსაზღვრავს tcpConnectionTable-ს, რომლის სტრიქონები აღწერს დამყარებულ TCP კავშირებს, გასაღებით მისამართის ტიპის, მისამართისა და პორტის მიხედვით ორივე ბოლოში. სტრიქონები ქრება კავშირის დახურვისას, ხოლო მოსმენითი სოკეტები სხვა ცხრილში ჩნდება. VPN-ის იმავე მანქანაზე გაშვება TCP ცხრილს IPsec უსაფრთხოების ასოციაციების ინვენტარად არ აქცევს. მან შეიძლება აღწეროს მართვის სესია, აპლიკაციის ნაკადი ან TCP-ზე გადატანილი გვირაბი და თავად სტრიქონი არ გეტყვით რომელი.

ინტერფეისის მრიცხველები იმავე გაურკვევლობას უფრო უხეშ დონეზე ატარებენ: ბაიტები ინტერფეისზე აერთიანებს ყველა პარტნიორს და ყველა ნაკადს, რომელიც მას იყენებს.

ააგეთ პატარა დაკვირვების კონტრაქტი

თითოეული მეტრიკისთვის ჩაწერეთ მხარდაჭერილი ობიექტი ან API ველი, მფლობელი მოწყობილობა და პროგრამული ვერსია, პარტნიორის ან სერვისის იდენტიფიკატორი, მიმართულება, შეგროვების დრო და მოსალოდნელი განახლების ქცევა. შემდეგ გამოიყენეთ კარიბჭის დოკუმენტირებული ასოციაციების ან სესიების ხედი პროტოკოლის მდგომარეობისთვის, მარშრუტიზაციის ცხრილი გზის მდგომარეობისთვის და ვიწრო ნებადართული მოთხოვნა აპლიკაციის მდგომარეობისთვის. მომუშავე მართვის საბოლოო წერტილი ამტკიცებს, რომ მართვის საბოლოო წერტილი მუშაობს და არაფერს მის უკან მდგარი აპლიკაციის შესახებ.

თუ დაყენებულ აგენტს არ აქვს საჭირო ობიექტები, აირჩიეთ სხვა ცალსახად მხარდაჭერილი მხოლოდ-კითხვის ინტერფეისი. OID-ის გამოგონება, ზოგადი TCP რაოდენობის გვირაბების რაოდენობად წაკითხვა ან ძველი ვენდორის API-ის უცვლელად გადარჩენის მოლოდინი დობილ პროდუქტში — ეს ყველაფერი ჩიხებია.

ძველი მონაცემები გვირაბის უკმარისობა არ არის

შეგროვების დროის ამოწურვა, ვადაგასული სერტიფიკატი ან შეცვლილი API გზა ქმნის დაკარგულ ტელემეტრიას. ეს მონიტორინგის უკმარისობაა და განსხვავებული ინციდენტი ჩამოვარდნილი გვირაბისგან. ჩაწერეთ, რომელი დაკვირვება როდის მოძველდა, რათა ოპერატორმა მიიღოს შინაარსიანი პირველი შემოწმება გვირაბის გადატვირთვის ნაცვლად. ყოველი დროის ამოწურვის VPN შეწყვეტად განხილვა ასწავლის ადამიანებს ორივეს უგულებელყოფას.

შეგროვების უფლებებიც ვიწროდ დაიჭირეთ. ინტერფეისი, რომელსაც შეუძლია კონფიგურაციის შეცვლა ან სესიების გასუფთავება, ატარებს პრივილეგიის საზღვარს, რომელიც მონიტორინგის სამუშაოს არ უნდა მემკვიდრეობით მიიღოს, და მხოლოდ-კითხვის ანგარიში ჩვეულებრივ საკმარისია.

სასარგებლო დიზაინი ასახელებს ობიექტს, მნიშვნელობას და სიახლის მოთხოვნას. პროტოკოლის არჩევა მათგან გამომდინარეობს და არა პირიქით.