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

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

ტესტამდე ჩაწერეთ ორივე საიტის მარშრუტები

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

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

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

დააკვირდით მოთხოვნებს და პასუხებს თითოეულ ეტაპზე

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

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

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

მართეთ სესიის მდგომარეობა, როცა შესასვლელი იცვლება

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

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

გამოცადეთ აპლიკაცია, რომელიც გრძელ სესიას ინახავს და არა მხოლოდ ახალ მოთხოვნას.

აღადგინეთ ძირითადი გზა და შეამოწმეთ რყევა

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

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

დაკავშირებული სტატიები