მფრინავი VPN სარეზერვო მარშრუტი არ იღებს გადაბარებას: გადართვის შემოწმების სია

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

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

დაასახელეთ ხარვეზი, რომელიც რეზერვმა უნდა დაფაროს

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

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

შეწყვიტეთ მანძილისგან რაიმეს აღმოჩენის მოთხოვნა

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

სტატიკური მარშრუტებისთვის ეს მოითხოვს ცხად მეთვალყურეს:

/ip route
add dst-address=10.20.0.0/24 gateway=192.0.2.1 distance=1 check-gateway=ping
add dst-address=10.20.0.0/24 gateway=wg-backup distance=10

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

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

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

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

/ip route print detail where dst-address=203.0.113.10
# gateway should still be the primary next hop

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

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

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

შეამოწმეთ დაბრუნების გზა და სესიების ისტორია

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

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

შეასრულეთ მიღების თანმიმდევრობა

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

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