AWS–Azure საიტთაშორისო VPN: ჯერ დაბრუნების მარშრუტი დაწერეთ
დაკავშირებული ღრუბლოგამშორისი გვირაბი არაფერს ამტკიცებს, სანამ ყოველი სამუშაო დატვირთვის ქვექსელი შორეულ პრეფიქსამდე არ მარშრუტდება. გაიარეთ გეგმა რიგრიგობით და შემდეგ გამოსცადეთ სერვისი.
გვირაბი ამოვა. ჩვეულებრივ ასე ხდება, რადგან IKE-ს მხოლოდ შესატყვისი შეთავაზებები და ხელმისაწვდომი პარტნიორის მისამართი სჭირდება. რაც შემდეგ ფუჭდება, დაბრუნების გზაა: AWS-ის დატვირთვა პაკეტებს გვირაბში აგზავნის, მაგრამ Azure-ის მხარეს არავინ იცის, როგორ უპასუხოს 10.10.0.0/16-ს, ან Azure-ის მარშრუტი იმ ცხრილშია, რომელსაც დატვირთვის ქვექსელი არ იყენებს. დაწერეთ მარშრუტების გეგმა ნებისმიერ კონსოლზე შეხებამდე და გვირაბი სამუშაოს ყველაზე ნაკლებად საინტერესო ნაწილი გახდება.
ნაბიჯი 1: გაყინეთ მისამართების გეგმა
იმუშავეთ კონკრეტული მნიშვნელობებით. AWS-ის დატვირთვა 10.10.1.20-ზეა 10.10.0.0/16-ის შიგნით და სჭირდება TCP 443 Azure-ის სერვისამდე 10.20.1.30-ზე 10.20.0.0/16-ის შიგნით. ორი დიაპაზონი არ უნდა გადაიფაროს და მიღების ტესტი სერვისების წყვილია, არა გვირაბი.
ჩაწერეთ ეს ოთხი ფაქტი ყველაფრამდე, რადგან ყოველი შემდეგი ნაბიჯი მათ წინააღმდეგ მოწმდება.
ნაბიჯი 2: დაასახელეთ კარიბჭე, რომელიც ფლობს ყოველ ბოლოს
AWS Site-to-Site VPN შეიძლება დასრულდეს ვირტუალურ კერძო კარიბჭეზე ან ტრანზიტულ კარიბჭეზე და ეს სხვადასხვა მარშრუტიზაციის მფლობელები არიან. Azure გთავაზობთ თავის მართულ VPN Gateway-ს და ცალკე VM-ზე დაფუძნებულ მოწყობილობებს, რომლებსაც მომხმარებლები თავად უშვებენ. ჩაწერეთ რომელი წყვილი გაქვთ, რადგან შემდეგი ნახტომი ყოველ კომბინაციაში განსხვავდება.
მართული კარიბჭისთვის ნუ დააკოპირებთ მარშრუტს, რომელიც სავარაუდო კერძო მოწყობილობის მისამართზე მიუთითებს. მოწყობილობისთვის ნუ ჩათვლით, რომ ღრუბელში მარშრუტების გავრცელება სტუმარ ოპერაციულ სისტემას აკონფიგურირებს, რადგან ამას არ აკეთებს.
აქ შეცდომა იძლევა გეგმას, რომელიც სრულად გამოიყურება და პაკეტებს იმ მისამართზე აგზავნის, რომელიც არასდროს პასუხობს.
ნაბიჯი 3: დაწერეთ მარშრუტი, რომელსაც ყოველი დატვირთვა რეალურად იყენებს
ქვემოთ ყოველი საზღვარი ცალკე ძებნაა და ერთ-ერთ მათგანში არსებული მარშრუტი პაკეტისთვის მარშრუტი არ არის. შეავსეთ ცხრილი თქვენი მნიშვნელობებით, სანამ გვირაბი ამუშავდება.
| Boundary | Must reach | Owner to inspect |
|---|---|---|
| AWS workload subnet | 10.20.0.0/16 | the subnet's VPC route table |
| AWS transit gateway, if used | 10.20.0.0/16 via the VPN attachment | the table associated with that attachment |
| Azure workload subnet | 10.10.0.0/16 | effective routes on the NIC, whatever their source |
| VPN scope | both prefixes, agreed | static connection ranges or BGP advertisements |
AWS-ში დატვირთვის ქვექსელის მარშრუტების ცხრილი თქვენი გასაახლებელია მას შემდეგაც, რაც BGP ან გვირაბი ჯანსაღი გახდება; მარშრუტიზაციის მიმოხილვა ამას კავშირის ნაწილად მიიჩნევს. Azure-ში მომხმარებლის განსაზღვრული მარშრუტების ცხრილი ქვექსელს უკავშირდება და არა ვირტუალურ ქსელს, ამიტომ ეფექტური მარშრუტი შეამოწმეთ დატვირთვის NIC-ზე და არა VNet-ის პანელში.
მართულ Azure კარიბჭეს შეუძლია შორეული პრეფიქსი კარიბჭის გავრცელებით ისწავლოს და UDR-მა შეიძლება ეს გადაწყვეტილება გააუქმოს. UDR დაამატეთ მაშინ, როცა მიზეზი გაქვთ და არა რეფლექსურად. თუ დაამატებთ, მიმართეთ იმ შემდეგ ნახტომზე, რომელსაც კარიბჭე VPN გზისთვის აქვეყნებს და ნუ გამოიგონებთ მოწყობილობის მისამართს. შემდეგ ხელახლა წაიკითხეთ ეფექტური მარშრუტები NIC-ზე, რადგან გადაწყვეტილება სინამდვილეში იქ მიიღება.
ნაბიჯი 4: შეათანხმეთ მოცულობა
BGP-ისთვის შეადარეთ რას აცხადებს თითოეული მხარე იმას, რაც მეორე მხარემ რეალურად ისწავლა, პრეფიქს-პრეფიქს. სტატიკური მარშრუტიზაციისთვის შეადარეთ კონფიგურირებული შორეული დიაპაზონები ნაბიჯ 3-ში დაწერილ დატვირთვის მარშრუტებს.
კრიპტოგრაფიაზე შეთანხმებული IKE კავშირი არ არის მტკიცებულება, რომ რომელიმე მხარემ ისწავლა 10.10.0.0/16 ან 10.20.0.0/16. ორი გვირაბი შეიძლება ამოვიდეს, სანამ ერთი მხარე თქვენ მიერ დაგეგმილი /16-ის ნაცვლად მხოლოდ /24-ს აცხადებს. პრეფიქსი შეამოწმეთ მარშრუტების ცხრილში და არა გვირაბის სტატუსში. შეუთანხმებლობა მოგვიანებით ჩნდება როგორც ერთი მომუშავე და ერთი არასდროს პასუხისმგებელი ქვექსელი.
ნაბიჯი 5: გამოსცადეთ სერვისი რეალური წყაროდან
დაუშვით განზრახული ნაკადი AWS-ის უსაფრთხოების ჯგუფებსა და ქსელურ ACL-ებში, Azure-ის NSG-ებში და გზაზე არსებულ ნებისმიერ მოწყობილობის ფილტრში. შემდეგ გახსენით ერთი კავშირი 10.10.1.20-დან დამტკიცებულ სერვისის მისამართზე და პორტზე და დაადასტურეთ, რომ პასუხი იმავე წყაროს უბრუნდება.
როგორც ღრუბლის უსაფრთხოების ჯგუფები, ისე NSG-ები მდგომარეობის მქონეა, ამიტომ უარყოფილი დაბრუნების პაკეტი მარშრუტიზაციის სიმპტომია და არა წესი, რომლის საპირისპიროდ დაწერა დაგავიწყდათ.
ნებისმიერი კარიბჭიდან ping არაფერს წყვეტს. კარიბჭის მისამართზე ICMP ავარჯიშებს მართვის სიბრტყის გზას და არა გადაცემულ TCP სერვისს, რომელიც დატვირთვას სჭირდება.
უკან დაბრუნება და ჩანაწერები
ჩაწერეთ მარშრუტების მფლობელები გვირაბის იდენტიფიკატორების გვერდით და შეინახეთ ცვლილებამდელი მარშრუტების ცხრილები. თუ ცვლილება უნდა მოიხსნას, წაშალეთ დატვირთვის მარშრუტები გვირაბის დანგრევამდე, რათა არც ერთი ქვექსელი არ დარჩეს იმ შემდეგ ნახტომზე მიმთითებელი, რომელიც აღარ არსებობს.
მაშინ ქვექსელის შემდგომ გადაადგილებას ან spoke-ის მიერთებას აქვს განახლების ერთი განსაზღვრული ადგილი, იმ მომუშავე გვირაბის ნაცვლად, რომელიც იტვირთავს ბრალს მარშრუტისთვის, რომელიც არასდროს ყოფილა მისი.