Cloud VPN-ის BGP მისამართები გვირაბის შიგნითაა და არა ქსელის ბარათზე

გახსენით VPN-ის Cloud Router გვერდი და 169.254.0.0/16-ში მისამართის მქონე BGP სესია თქვენკენ იყურება. ბუნებრივი რეაქციაა ის, რომ ეს მისამართი სადმე VM-ზე მოათავსოთ და დაელოდოთ სესიის აწევას. ეს რეაქცია კონკრეტული გზით მცდარია: წყვილი ეკუთვნის იმ ლოგიკურ კავშირს, რომელსაც IPsec გვირაბი ქმნის და არა მანქანის ჩვეულებრივ ქსელურ ინტერფეისს. არაფერი, რასაც NIC-ზე დაამატებთ, არ აიძულებს გვირაბს BGP-ის ტარებას.

მიჰყევით წყვილს სტეკში ქვემოთ, ნაცვლად იმისა, რომ ჰოსტს დაუმატოთ.

დაიწყეთ იქ, სადაც კონსოლი წყვილს აჩვენებს

სესიის გვერდი ჩამოთვლის Cloud Router-ის BGP მისამართს და პარტნიორის მისამართს, ორივე link-local-ია IPv4 HA VPN-ისთვის. მათ გვერდით არის გარე კარიბჭეების მისამართები, რომლებიც გვირაბებს ასრულებენ. ეს სხვადასხვა ობიექტია: link-local წყვილი შიგნით ცხოვრობს, ხოლო კარიბჭის მისამართები გარეთ ცხოვრობს და უნდა იყოს მარშრუტიზებადი, სანამ სხვა რამე იმუშავებს.

ჩაწერეთ სამივე კონფიგურაციის ფაილის გახსნამდე, რადგან მათი არევა მთელი მარცხის რეჟიმია.

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

link-local წყვილი მნიშვნელობას მხოლოდ მაშინ იძენს, როცა ორ კარიბჭეს შორის IPsec უსაფრთხოების ასოციაცია არსებობს. Google-ის მხარეს HA VPN გვირაბები მას ორ ინტერფეისზე ქმნიან; თქვენს მხარეს ეს არის ის, რაზეც პარტნიორმა იმუშავა. ჯერ შეამოწმეთ მონაცემთა ასოციაცია swanctl --list-sas-ით და ჩაწერეთ, რომელი გვირაბი რომელ ინტერფეისზეა აწეული, რადგან ჯანსაღი BGP სესია მკვდარ გვირაბზე შეუძლებელია, ხოლო იმედიანი კონფიგურაციით მკვდარი გვირაბი ჩვეულებრივი მოვლენაა.

BGP პაკეტი შიდა IP ტრაფიკია. გარე ქსელი მას ვერასდროს ხედავს, ამიტომ არცერთ გადამრთველს ორივე მისამართი ერთ VLAN-ზე არ სჭირდება.

ახლა დააკონფიგურეთ Linux პარტნიორი შესაბამისობისთვის

აირჩიეთ მხარდაჭერილი გვირაბის დიზაინი და მიეცით მას შიდა მისამართების განსაზღვრის უფლება. მარშრუტზე დაფუძნებული ინტერფეისის შემთხვევაში მარშრუტის ჩანაწერი და შეთანხმებული ტრაფიკის სელექტორები უნდა ემთხვეოდეს, რადგან მხოლოდ ინტერფეისის სახელი არაფერს ნებას აძლევს. მიმართეთ BIRD შიდა ლოკალურ მისამართზე და Cloud Router-ის შიდა მისამართზე, დააყენეთ AS ნომრები სესიის გვერდიდან და დაუშვით TCP 179 დაცული გზის შიგნით. შეინახეთ მარშრუტი შორეულ გარე მისამართზე ფიზიკურ აპლინკზე, რათა გვირაბმა საკუთარი ტრანსპორტი არ დაიჭიროს.

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

შეამოწმეთ ყოველი ეტაპი რიგრიგობით და არა ყველაფერი ერთად

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

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

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

გაჩერდით, სანამ ამას Router Appliance-ზე გამოიყენებთ

Network Connectivity Center Router Appliance სხვა მიმაგრების მოდელია. მისი Cloud Router პარტნიორები იყენებენ შიდა მისამართებს VPC-ის და ქვექსელის განლაგებიდან და არა HA VPN-ის link-local წყვილს. თუ ნამდვილი მიზანი BGP-ია მარშრუტიზაციის VM-თან, მიჰყევით იმ პროდუქტის ინტერფეისის მოთხოვნებს და ნუ დააკოპირებთ link-local სესიას.

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