GCP HA VPN: BGP სესია Waiting for peer-ზე ჩერდება, მისამართების წყვილის შენაცვლება
Cloud VPN-ის BGP სესია, რომელიც Waiting for peer-ზე შეჩერდა, ჩვეულებრივ გვირაბისა და პირის მისამართები აქვს შენაცვლებული. წყვილი შეამოწმეთ, სანამ რამეს ხელახლა ააგებთ.
BGP სესია, რომელიც Cloud VPN-ის გვირაბზე არასოდეს აღწევს Established მდგომარეობას, ჩვეულებრივ მარშრუტიზაციის პრობლემა არ არის. ეს გაყვანილობის პრობლემაა: ორი მისამართი, რომლებიც ერთმანეთის სარკისებური უნდა იყოს, არასწორი თანმიმდევრობით შეიყვანეს, ან პირველი გვირაბის წყვილი მეორეზე ხელახლა გამოიყენეს. თავად გვირაბი შეიძლება სრულიად ჯანმრთელი იყოს, სანამ სესია Waiting for peer-ზე დგას, რადგან IPsec და BGP ერთი და იმავე ორი ბოლო წერტილის ცალკეული მოლაპარაკებებია. გადაწყვიტეთ, რომელია ამ ორიდან გატეხილი, სანამ რამეს ხელახლა ააგებთ.
ერთი კითხვა წყვეტს შემთხვევათა უმეტესობას: ხედავს პირის მოწყობილობა Cloud Router-ის მისამართს საერთოდ?
გვირაბის მდგომარეობა და სესიის მდგომარეობა სხვადასხვა შემოწმებაა
ჯერ IKE და ESP მოდის. თუ გვირაბი დამყარებული არ არის, მის შიგნით არაფერს აქვს მნიშვნელობა და BGP მისამართის განხილვა ნაადრევია. წაიკითხეთ გვირაბის სტატუსი და დეტალური სტატუსი, შემდეგ მარშრუტიზატორის BGP პირის სტატუსი იმავე გვირაბისთვის.
გვირაბი, რომელიც მუშაობს, სანამ მისი BGP პირი გამორთულია, ავიწროებს ხარვეზს სესიამდე: პირის მისამართი, ASN ან TCP 179, რომელიც შიდა მისამართზე მოდის. გვირაბი მუშაობს, სესია მუშაობს და ჯერ კიდევ არ არის მარშრუტები VPC-ში ეს მესამე შემთხვევაა. მისამართების შეცვლა იქ არ დაგეხმარებათ, რადგან სესია უკვე მუშაობს და პრეფიქსი უბრალოდ არ რეკლამირდება ან არ სარგებლობს უპირატესობით. ამ სამი შემთხვევის გამიჯვნა სამუშაოს უდიდესი ნაწილია.
თითოეულ გვირაბს საკუთარი /30 სჭირდება, ორივე ბოლოთი შევსებული
ყოველი HA VPN გვირაბი იღებს link-local /30-ს 169.254.0.0/16-დან, ერთი მისამართი Cloud Router-ის ინტერფეისზე და მეორე თქვენს პირზე. პირის ველი უნდა ასახელებდეს შორეულ ბოლოს, არასოდეს მარშრუტიზატორის საკუთარ მისამართს.
ორი გვირაბი ნიშნავს ორ ინტერფეისს Cloud Router-ზე, თითოეული განსხვავებული /30-ით. 0 გვირაბის წყვილის ხელახლა გამოყენება 1 გვირაბზე ის შეცდომაა, რომელიც შემაჯამებელ ცხრილში მოწესრიგებულად გამოიყურება და OPEN პაკეტში იღუპება.
| Tunnel | Router interface | Peer address | What a swap produces |
|---|---|---|---|
| tunnel 0 | 169.254.1.1/30 | 169.254.1.2 | OPEN sent to itself or to nothing; session waits |
| tunnel 1 | 169.254.1.5/30 | 169.254.1.6 | same failure on the second session |
| both | one pair reused | one address reused | one session up, the other never leaves waiting |
წყვილი წაიკითხეთ მარშრუტიზატორის რესურსიდან და არა კონსოლის შეჯამებიდან. შეჯამება პირის მისამართს ისეთ სვეტში ჩამოთვლის, რომლის არასწორად წაკითხვა ადვილია, და ინტერფეისის ipRange პლუს პირის peerIpAddress უნდა აღწერდეს ერთი /30-ის საპირისპირო ბოლოებს.
შენაცვლება ჩვეულებრივ გადაკეთების დროს ხდება
სწორედ გვირაბის გადაკეთებისას იკვეთებიან წყვილები. ძველი გვირაბის პირის მისამართი ახალი გვირაბის ინტერფეისის ველში კოპირდება, ან ახალი სესია წინა სესიის პირზე მიმართულდება. ნებისმიერ შემთხვევაში Cloud Router OPEN პაკეტებს უგზავნის მისამართს, რომელიც ახლა თავად არის, ან მისამართს, რომლის უკან გვირაბი არ არის.
ჩაწერეთ წყვილები კონსოლის გახსნამდე: გვირაბის სახელი, ინტერფეისი, მარშრუტიზატორის მისამართი, პირის მისამართი, პირის ASN. შემდეგ შექმენით ორივე გვირაბი ერთ გავლაში, რომ მეორე პირველის ნაშთებით არ შეივსოს.
კიდევ სამი მიზეზი, რატომ ელოდება სესია
პირველი პირის ASN-ია: თითოეული მხარე მეორე მხარის ASN-ით უნდა იყოს კონფიგურირებული, და შეუთანხმებლობა პირამდე აღწევს, მაგრამ არასოდეს მყარდება. მეორე თავად პირის ფაირვოლია, რომელმაც უნდა დაუშვას TCP 179 გვირაბის ინტერფეისზე; IKE ან ESP წესი ამას არ ფარავს. მესამე პირია, რომელიც სხვა წყაროს მისამართიდან პასუხობს, ვიდრე ის, რაც მის მეზობლად არის კონფიგურირებული.
პირის საკუთარი ჟურნალია განმასხვავებელი. თუ მისი BGP შეჯამება ამ მისამართისთვის მეზობელს არ ჩამოთვლის, პაკეტები არ მოდის და წყვილი ან გზა არასწორია. თუ მეზობელი Active ან Connect-ში დგას, პაკეტები მოდის და სესიის პარამეტრები არ თანხვედრობს.
შეამოწმეთ იმ თანმიმდევრობით, რომლითაც პაკეტები მოძრაობენ
იმუშავეთ გარეთკენ: გვირაბის სტატუსი, შემდეგ მარშრუტიზატორის BGP პირის სტატუსი, შემდეგ პირის BGP შეჯამება, შემდეგ მარშრუტები. თუ პირველი ორი ჯანმრთელია, შეწყვიტეთ Cloud VPN-ის მხარის რედაქტირება და იმუშავეთ პირის მოწყობილობაზე. თუ მარშრუტიზატორი პირს გამორთულად აცხადებს და თქვენს მოწყობილობას მეზობელი არ ჰყავს, წყვილი არასწორია ან BGP პორტი გაფილტრულია. პაკეტების ჩაჭერა პირის გვირაბის ინტერფეისზე ერთი შეხედვით წყვეტს ამას, რადგან OPEN პაკეტები ან იქ აღწევენ, ან არასოდეს აღწევენ.
gcloud compute routers get-status ROUTER --region=REGION ბეჭდავს პირის მდგომარეობას იმ მისამართის გვერდით, რომელსაც იყენებს, და ეს ზუსტად ის წყვილია, რომელიც უნდა შეადაროთ.
როცა სესია დამყარდება, დაადასტურეთ, რომ ნასწავლი პრეფიქსი VPC-ის მარშრუტების ცხრილში ჩნდება და რომ თითოეულ მხარეს ერთი ჰოსტი პასუხობს. შემდეგ ჩაწერეთ საბოლოო წყვილები გვირაბების სახელების გვერდით, რათა შემდეგი გადაკეთება დადასტურებული ცხრილიდან დაიწყოს და არა კონსოლის შეჯამებიდან.