ღრუბლოვან VPN-ს BGP სჭირდება: რატომ ვერ მუშაობს სხვა მარშრუტიზაციის პროტოკოლები
გვირაბი აწეულია და პრეფიქსი არასდროს ჩნდება. მართული ღრუბლოვანი VPN-ები BGP-ს იყენებენ როგორც მარშრუტიზაციის კონტრაქტს, ამიტომ ჯერ სერვისის მოთხოვნა შეამოწმეთ.
IPsec უსაფრთხოების ასოციაცია აწეულია, გვირაბის მრიცხველები მოძრაობს, და ღრუბლოვან პრეფიქსზე ტრაფიკი ქრება. ოპერატორი შემდეგ ცდილობს OSPF-ის ჩართვას კლიენტის როუტერზე, ელოდება მეზობლის ფორმირებას, და არაფერი ხდება. გვირაბი არასდროს ყოფილა დაკარგული ნაწილი: მართული ღრუბლოვანი VPN ავლენს განსაზღვრულ მარშრუტიზაციის კონტრაქტს, და დიდ პლატფორმებზე ეს კონტრაქტი BGP-ია. სანამ სესია არ არსებობს და პრეფიქსი არ მიიღება, გვირაბი მხოლოდ დაშიფრული გზაა მის უკან დანიშნულების გარეშე.
გვირაბი აწეულია, მარშრუტი კი აკლია
ფაზა 1-ის და ფაზა 2-ის დასრულება ამტკიცებს, რომ მხარეები თანხმდებიან დაცვაზე, და არა იმას, რომ რომელიმე მათგანმა იცის სად გაგზავნოს ტრაფიკი. ეს ცალკეული მდგომარეობის მანქანებია ცალკეული უკმარისობის რეჟიმებით.
დასვით სამი კითხვა თანმიმდევრობით: გამოცხადდა პრეფიქსი, მიიღო თუ არა ის მეზობელმა, და დაყენდა თუ არა ის გადამისამართებისთვის? გამოცხადებული და გაფილტრული პრეფიქსი პოლიტიკის პრობლემაა. არასდროს გამოცხადებული პრეფიქსი სესიის ან კონფიგურაციის პრობლემაა. მიღებული, მაგრამ დაუყენებელი პრეფიქსი მარშრუტის არჩევის პრობლემაა, და ყოველი პასუხი კონფიგურაციის სხვადასხვა ნაწილზე მიუთითებს.
რას გაძლევთ პროვაიდერი სინამდვილეში
მართული VPN შესასვლელი შეუზღუდავი როუტერი არ არის. პროვაიდერი გაძლევთ შესასვლელს მხარდაჭერილი მეზობლის მისამართებით, ავტონომიური სისტემის პარამეტრით, პრეფიქსის ლიმიტებით და განსაზღვრული უკმარისობის ქცევით. ეს ზედაპირია პროდუქტი.
Google Cloud ადასტურებს დინამიკურ BGP მარშრუტიზაციას HA VPN-ისთვის, სადაც Cloud Router სწავლობს მეზობლის მარშრუტებს და VPC-ს აწვდის შესაბამის ინდივიდუალურ დინამიკურ მარშრუტებს. AWS Site-to-Site VPN ადასტურებს არჩევანს სტატიკურ და დინამიკურ მარშრუტიზაციას შორის და აღწერს BGP სიცოცხლისუნარიანობის შემოწმებებს როგორც სასარგებლოს გვირაბის გადართვისთვის, ამავდროულად მხარს უჭერს ჯანმრთელობის შემოწმებებს BGP-ს გარეშე მოწყობილობებისთვის. არც ერთი პლატფორმის ქცევა არ უნდა გამოიტანოს მეორის პროდუქტის სახელიდან.
პრაქტიკული შედეგია, რომ ჯერ ირჩევთ მართულ რეჟიმს, შემდეგ კითხულობთ მხარდაჭერილ პარამეტრებს. დიზაინი, რომელიც ითვალისწინებს მეზობლობის ტიპს, რომელსაც სერვისი არ გთავაზობთ, არ არის კონფიგურაციის პრობლემა, რომელიც კლიენტის როუტერზე უნდა გადაწყდეს.
გვირაბის დაცვა და ხელმისაწვდომობა ცალკეული სამუშაოებია
IPsec იცავს იმ ტრაფიკს, რომელიც გვირაბისთვის არის შერჩეული. BGP აწვდის ხელმისაწვდომობის ინფორმაციას, რომელიც პრეფიქსს შესაბამისს ხდის. მოქმედი გვირაბი არ ამტკიცებს, რომ მოსალოდნელი პრეფიქსი გამოცხადდა, მიიღეს ან დააყენეს.
წარმოიდგინეთ ფილიალი, რომელიც 10.42.0.0/16-ს აცხადებს ორი შესაბამისი გვირაბის გზით. მოხსენით ერთი გამოსაყენებელი გზა და მარშრუტის არჩევა შეიძლება შეიცვალოს ისე, რომ არავინ შეცვალოს თითოეული დატვირთვის მარშრუტი. გამოვლენა, მარშრუტის არჩევა და აპლიკაციის აღდგენა მყისიერი არ არის და არ არის იდენტური განლაგებებს შორის, ამიტომ გადართვის ტესტმა უნდა დააკვირდეს მთელ მიმდევრობას და არა პირველ გამავალ პაკეტს.
როცა ღრუბლოვანი პრეფიქსი მიუწვდომელია, შეამოწმეთ სესიის მდგომარეობა და ნასწავლი მარშრუტები სანამ კრიპტოგრაფიას შეეხებით. მოქმედი SA მის უკან მარშრუტის გარეშე ამ სიმპტომის ყველაზე გავრცელებული ფორმაა.
სად იმსხვრევა OSPF-ის ვარაუდები
OSPF, IS-IS ან სხვა პროტოკოლი IPsec გვირაბის შიგნით სავსებით შესაძლებელია თვითმართულ მოწყობილობაზე, სადაც ორივე ბოლო და გადამისამართების დიზაინი თქვენ გაქვთ. ეს ფაქტი არაფერს ამბობს მართულ სერვისზე, რომელიც დინამიკური მარშრუტიზაციის რეჟიმად მხოლოდ BGP-ს გთავაზობთ.
თუ შემოთავაზებულ დიზაინს სჭირდება მეზობლობა, რომელსაც სერვისი არ უჭერს მხარს, შეცვალეთ არქიტექტურა განზრახ. ვარიანტები მოიცავს თვითმართულ მოწყობილობას VPC-ში, სტატიკურ მარშრუტიზაციას სადაც სერვისი უჭერს მხარს, ან სხვა კავშირის პროდუქტს. პროტოკოლის მხოლოდ კლიენტის როუტერზე კონფიგურაცია ვერ დაამატებს ღრუბლის მხარეს არარსებულ მეზობელს და არ გამოიწვევს პრეფიქსის გამოჩენას.
ნუ გადაიტანთ ერთი მომწოდებლის პასუხს მეორის შესასვლელზე. იგივე სიტყვები, როგორიცაა დინამიკური მარშრუტიზაცია ან გვირაბის გადართვა, შეიძლება აღწეროს სხვადასხვა მექანიზმი და სხვადასხვა ზღვარი.
წაიკითხეთ სერვისის მოთხოვნა, შემდეგ დააპროექტეთ
პირველ კონფიგურაციის ხაზამდე ჩაწერეთ მეზობლების მისამართები, ავტონომიური სისტემების ნომრები, პრეფიქსები, რომლებსაც გამოაცხადებთ და მიიღებთ, მარშრუტების ლიმიტები და მოსალოდნელი ქცევა გვირაბის უკმარისობისას. ეს ხუთი პუნქტია კონტრაქტი, რომლის მიხედვითაც პროექტირებთ.
შემდეგ გადაამოწმეთ იმავე თანმიმდევრობით: სესია დამყარებულია, პრეფიქსი მიღებულია, მარშრუტი არსებობს VPC-ის მარშრუტების ცხრილში და არის რეალური ნაკადი სერვისის მისამართზე. გაიმეორეთ იძულებითი გადართვის შემდეგ, რადგან ხელახლა დამყარებული სესია შეიძლება დაბრუნდეს მარშრუტების სხვა ნაკრებით. თუ დიზაინი დამოკიდებულია წამზე ნაკლებ კონვერგენციაზე, გაზომეთ ის და ნუ ჩათვლით.
შეინახეთ სერვისის კონტრაქტი ცვლილების ჩანაწერთან ერთად. როცა მოგვიანებით ვიღაც იკითხავს რატომ ვერ უშვებს გვირაბი OSPF-ს, პასუხი პროდუქტის საზღვარია და არა პროტოკოლის შეზღუდვა, და ჩანაწერმა ეს უნდა თქვას.