ლოკალური ქვექსელის დამატება AWS VPN-ზე: VGW თუ Transit Gateway

არსებული Site-to-Site VPN გადააქვს 10.60.0.0/16-ს, იმავე ლოკალური კარიბჭის უკან ჩნდება ახალი სერვისული ქსელი 10.70.0.0/16-ის სახით, და ვიღაც კითხულობს, საჭიროა თუ არა პროქსი. ჩვეულებრივ არა: მარშრუტიზებულ გზას შეუძლია პრეფიქსის გადატანა, მაგრამ მხოლოდ მაშინ, თუ სამი რამ ემთხვევა, და რომელი სამი — დამოკიდებულია AWS არქიტექტურაზე, რომელსაც უკვე ამუშავებთ. ვირტუალურ კერძო კარიბჭეს ერთი მარშრუტიზაციის ცხრილის საზღვარი აქვს; transit gateway მეორეს ამატებს. სწორი განცხადება და არასწორი ცხრილი ქმნის სესიას, რომელიც ჯანმრთელად გამოიყურება და არაფერს აწვდის.

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

ლოკალურ კარიბჭეს სჭირდება გზა ახალი ქსელისკენ, სანამ რომელიმე განცხადებას აზრი ექნება. 10.70.0.0/16-ის BGP-ით გამოცხადება AWS-ს ეუბნება, სად გაგზავნოს ამ დიაპაზონის პაკეტები; ის არ ქმნის ლოკალურ გადამისამართების გზას, რომელიც დიაპაზონს მეორე ბოლოში ხელმისაწვდომს ხდის. დარწმუნდით, რომ კარიბჭეს აქვს პრეფიქსის მარშრუტი, რომელიც მიუთითებს მის მფლობელ მოწყობილობაზე, და რომ მოწყობილობა კონფიგურირებულია ამ მისამართებზე პასუხის გასაცემად. ექსპორტის პოლიტიკა და მიღებული პრეფიქსის ლიმიტები შემდეგი შეზღუდვაა, რადგან სესიის მიერ გაფილტრული პრეფიქსი AWS-მდე საერთოდ არ აღწევს.

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

გზა პირველი: ვირტუალური კერძო კარიბჭის საზღვარი

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

ჯანმრთელი BGP სესია ამტკიცებს, რომ არხი არსებობს. ის არაფერს ამბობს იმაზე, მიიღო თუ არა მოცემულმა ქვექსელის ცხრილმა ეს მარშრუტი.

გზა მეორე: transit gateway ცხრილს ამატებს

Transit gateway ერთ კითხვას ორად ყოფს. VPC-ის ქვექსელმა დანიშნულება transit gateway-ის მიმაგრებას უნდა გაუგზავნოს, შემდეგ კი transit gateway-ის მარშრუტიზაციის ცხრილმა იმავე პრეფიქსისთვის VPN-ის მიმაგრება უნდა შეარჩიოს. ასოციაციისა და პროპაგაციის არჩევანი განსაზღვრავს, რომელი მიერთებული ქსელები მიიღებენ მარშრუტს, ამიტომ პრეფიქსი შეიძლება სწორად გამოცხადდეს VPN-ის მიერ და მაინც ვერასდროს მიაღწიოს იმ VPC-ს, რომლის ცხრილიც არასდროს დაუკავშირდა სწორ მარშრუტიზაციის ცხრილს.

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

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

დაბრუნების გზა დამოუკიდებელი პოლიტიკური გადაწყვეტილებაა

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

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

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

როცა პროქსი ნამდვილად უკეთესი საზღვარია

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

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