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

Request: branch -> VPN gateway -> NVA A -> workload
Reply:   workload -> NVA B -> VPN gateway -> branch

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

რას პროგრამავს Route Server სინამდვილეში

Azure Route Server მეგობრობს მხარდაჭერილ BGP მოსაუბრეებთან, სწავლობს მათ მარშრუტებს და პროგრამავს მათ ვირტუალური ქსელის ეფექტურ მარშრუტებში. ეს საკონტროლო სიბრტყის სამუშაოა. ის არ კითხულობს ვენდორის firewall-ის სესიების ცხრილს და არ იცის, რომელმა მოწყობილობამ დაუშვა მოცემული კავშირი. ორი თანაბარი ღირებულების შემდეგი ჰოპი ამ ქსოვილისთვის უბრალოდ ერთი და იმავე პრეფიქსამდე მისვლის ორი გზაა და ნებისმიერს გამოიყენებს.

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

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

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

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

სად ცხოვრობს მდგომარეობა

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

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

მხარდაჭერილი HA მოდელები და რას ჰპირდება თითოეული

Microsoft's guidance on Virtual WAN მარშრუტიზაციის განზრახვაზე აღწერს შეზღუდულ ქცევას ორმაგი როლის კავშირისა და firewall NVA-ებისთვის, სადაც პირდაპირ მარშრუტიზაციას შეუძლია გვერდი აუაროს hub-ის ჩვეულ სიმეტრიულ აღსრულებას. წაიკითხეთ ეს ჩანაწერები, როგორც შეზღუდვები არჩეულ ტოპოლოგიაზე და არა როგორც აქტიურ-აქტიური დიზაინების აკრძალვა. ვენდორის წყვილი, რომელიც მდგომარეობას სინქრონიზებს ან ნაკადის მიხედვით მართავს, შეიძლება იყოს მხარდაჭერილი. თანაბარი ღირებულების წყვილი, რომელიც არცერთს არ აკეთებს, არ არის.

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

რა უნდა შემოწმდეს მანამდე, სანამ ენდობით

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

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

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

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