IKEv2-ის მკვდარი პარტნიორის ამოცნობა თქვენს აპს არ ამოწმებს

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

წაიკითხეთ ორი სახის მტკიცებულება ცალკე, სანამ ტაიმერს შეცვლით.

რას ითხოვს სინამდვილეში სიცოცხლის შემოწმება

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

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

უსაფრთხოების ასოციაციები ბრაუზერამდე წაიკითხეთ

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

ipsec statusall | head -n 40
swanctl --list-sas
ip xfrm state | grep -E 'proto|mode'

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

მარშრუტის მარცხი ზუსტად მკვდარ პარტნიორს ჰგავს

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

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

ტაიმერები დიაგნოზს მიღმა დაიტოვეთ

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

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

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