როგორ გადავამისამართოთ SaaS ტრაფიკი სწორ მომხმარებლის VPN-ში
გადამკვეთი მომხმარებლის ქვექსელები ამტვრევს საზიარო მარშრუტიზაციას. აირჩიეთ იზოლაციის მოდელი, მიაბით ყოველი სამუშაო დადასტურებულ მოიჯარეს და გაშვებამდე შეამოწმეთ მარშრუტები მოიჯარეებს შორის.
SaaS პლატფორმა უკავშირდება ათეულ მომხმარებლის ქსელს, და ამ მომხმარებლებიდან ორი იყენებს 10.20.0.10-ს თავიანთი ძირითადი მონაცემთა ბაზისთვის. მუშაკი, რომელიც სამუშაოში იღებს ამ მისამართს, ვერ იგებს, რომელი მონაცემთა ბაზა იგულისხმება, და საზიარო მარშრუტიზაციის ცხრილი სიამოვნებით გაუგზავნის იმ გვირაბს, რომლისკენაც პრეფიქსი მიუთითებს. გადაწყვეტა მეტი გვირაბი არ არის; გადაწყვეტა არის გადაწყვიტოთ, სად შემოდის მოიჯარის იდენტობა გზაზე და რომელი იზოლაციის მოდელი სჭირდება მისამართების გეგმას. სამი პირობა წყვეტს არჩევანს: ემთხვევა თუ არა მომხმარებლის პრეფიქსები, რამდენად შორს შეიძლება გავრცელდეს შეცდომა და ვინ მართავს კონექტორს.
ორი მომხმარებლის მონაცემთა ბაზა, ერთი დანიშნულების მისამართი
IP მისამართი ადგილია, არა იდენტობა. მოთხოვნამ უნდა ატაროს მოიჯარე, რომელიც სერვერმა დაადასტურა, და ამ მოიჯარემ უნდა აირჩიოს ქსელის კონტექსტი სანამ დანიშნულება გადაწყდება.
როცა ეს არ ხდება, წარუმატებლობა ჩუმია. კავშირი წარმატდება, მოთხოვნა სრულდება და პასუხი მოდის არასწორი მომხმარებლის მონაცემთა ბაზიდან, რადგან მარშრუტიზაციის ცხრილში ერთი ჩანაწერი იყო 10.20.0.10-ისთვის. DNS აუარესებს: ქეშირებული სახელი, რომელიც მოიჯარე A-ს კონტექსტში გადაწყდა, შეიძლება ხელახლა გამოიყენოს მოიჯარე B-სთვის მომუშავე სამუშაომ. პაკეტში არაფერი განასხვავებს ორივეს, ამიტომ არც ერთი ხელახალი ცდის ლოგიკა არ ასწორებს ამას.
ჯერ იზოლაციის მოდელი გადაწყვიტეთ
ჩაწერეთ სამი პირობა პროდუქტების შედარებამდე. გადაკვეთა წყვეტს შეიძლება თუ არა ერთი მისამართების სივრცის გაზიარება; ზემოქმედების რადიუსი წყვეტს მარშრუტიზაციის შეცდომა დახმარების ბილეთია თუ დარღვევა; ოპერაციული საკუთრება წყვეტს შეგიძლიათ თუ არა კონექტორების ფლოტის მართვა თითო მოიჯარეზე.
| Condition | Hub with per-tenant route tables | Per-tenant connector context |
|---|---|---|
| Customer CIDRs overlap | No, unless you add 1:1 NAT | Yes, each context keeps its own view |
| A mistake must stay inside one VPC | Weak, routing is shared infrastructure | Strong, each connector has its own egress |
| You can run one fleet per tenant | Not required | Required |
თუ პრეფიქსები განსხვავებულია და პოლიტიკა ნებას რთავს კონტროლირებად ჰაბს, ერთი Transit Gateway მოიჯარეზე მარშრუტიზაციის ცხრილებით შესაძლებელია. დანართის ასოციაცია ირჩევს მარშრუტიზაციის ცხრილს, რომელიც გამოიყენება ამ დანართიდან მომავალი ტრაფიკისთვის, ხოლო გავრცელება ირჩევს, რომელი მარშრუტები გამოჩნდება ცხრილში. მოიჯარის დანართი, რომელიც მხოლოდ საკუთარ ცხრილთან არის დაკავშირებული და მხოლოდ საკუთარ პრეფიქსებს ავრცელებს, აღწევს ჰაბს და სხვაგან არსად. ეს მარშრუტიზაციის გადაწყვეტილებაა და სწორი რჩება მხოლოდ მანამ, სანამ არავინ დაამატებს ნაგულისხმევ მარშრუტს საზიარო ცხრილში.
თუ პრეფიქსები ემთხვევა, მხოლოდ მარშრუტიზაცია ვერ გაჰყოფს მათ. გჭირდებათ ან ცალკე ქსელის კონტექსტი თითო მოიჯარეზე, ან თარგმანის გეგმა, რომელიც თითოეული მომხმარებლის სივრცეს ცალსახა მნიშვნელობას აძლევს.
რას ნიშნავს სინამდვილეში Transit Gateway-ის იზოლაცია
ასოციაცია და გავრცელება ორი მნიშვნელოვანი ღილაკია და ადვილია მათი არევა. ასოციაცია პასუხობს, რომელ ცხრილში იძებნება ამ დანართის პაკეტი; გავრცელება პასუხობს, რომელი ცხრილები სწავლობენ ამ დანართის მარშრუტებს. იზოლაცია მოდის ორივეს მოიჯარეზე სპეციფიკურად გახდომიდან და არა მეტი დანართის შექმნიდან.
ნაგულისხმევი ყველა-ყველასთან კონფიგურაცია მოსახერხებელია და იზოლაცია არ არის. ცალკე მარშრუტიზაციის ცხრილები ზღუდავს კავშირებს, მაგრამ ერთ უცვლელ დანიშნულების მისამართს ორ მნიშვნელობას არ აძლევს იმავე მარშრუტიზაციის კონტექსტში. თუ აპლიკაცია 10.20.0.10-ს გადაწყვეტს მოიჯარის ცოდნამდე, მარშრუტიზაციის ფენამ უკვე დაკარგა საჭირო ინფორმაცია.
AWS-მა 2026 წლის 23 ოქტომბერს დაამატა დანართის დონის 1:1 NAT Transit Gateway-ისა და Cloud WAN-ისთვის, რაც ცვლის გადაკვეთის პასუხს მხარდაჭერილი დანართებისთვის. Transit Gateway NAT-ის დოკუმენტაცია აღწერს სტატიკურ, მდგომარეობის გარეშე, თანაბარი პრეფიქსის IPv4 ასახვებს ჰოსტის ბიტების შენარჩუნებით. შეამოწმეთ მხარდაჭერილი დანართის ტიპები და რეგიონული შეზღუდვები მანამ, სანამ ამის გარშემო დააპროექტებთ.
მიაბით სამუშაო დადასტურებულ მოიჯარეს
ყოველმა სამუშაომ უნდა ატაროს სერვერის მიერ დადასტურებული მოიჯარის იდენტობა, და ამ იდენტობამ უნდა აირჩიოს ადმინისტრატორის საკუთრებაში არსებული კავშირის ჩანაწერი. ჩანაწერი ასახელებს დამტკიცებულ ქსელის კონტექსტს, სერვისის მისამართს, სერთიფიკატების მითითებას და იქ დაშვებულ ოპერაციებს. არასანდო მოთხოვნამ არასდროს არ უნდა მოგვცეს საკუთარი VPN იდენტიფიკატორი, კარიბჭე ან კერძო სამიზნე, რადგან ვალიდური შესვლა ნებართვა არ არის ყოველი დაკავშირებული მომხმარებლის მისამართების სივრცის გამოსაკვლევად.
იზოლირებული კონექტორების დიზაინში მოიჯარე A-ს სამუშაო მიდის A-სთვის სპეციფიკურ კონექტორთან, რომელიც მუშაობს A-ს VPC-ში და მხოლოდ A-ს დამტკიცებულ რესურსებს აღწევს. ერთ ჰოსტზე ცალკე კონტეინერები თავისით არ ქმნიან ამ განცალკევებას; ქსელის სახელების სივრცეებმა, მარშრუტებმა და გასვლის პოლიტიკამ უნდა განახორციელოს ის. კონექტორს ასევე სჭირდება მოიჯარეზე შეზღუდული სერთიფიკატები და რიგები, რადგან კერძო მარშრუტი არ ზღუდავს საზიარო საიდუმლოს ან საზიარო სამუშაო ერთეულს. გაერთიანებული აპლიკაციის მუშაკები ნორმალურია, სანამ ქსელის კონტექსტი და სერთიფიკატები ირჩევა მოიჯარეზე და არა ჰოსტზე.
ჯანმრთელობის შემოწმებებმა უნდა დაასახელონ მოიჯარე და ეტაპი: გვირაბი დამყარებული, მარშრუტი არსებული და რეალური სერვისის მოთხოვნა წარმატებული სამი განსხვავებული სიგნალია. აქტიური გვირაბების ჯამური რაოდენობა დამალავს იმ ერთ მომხმარებელს, რომლის კონექტორიც გატეხილია.
შეამოწმეთ გზები, რომლებიც უნდა ჩავარდეს
გაშვებამდე ჩაატარეთ სამი ტესტი. დაშვებული A ოპერაცია უნდა წარმატდეს, დაშვებული B ოპერაცია უნდა წარმატდეს, და განზრახ B-ს კონექტორზე ან მის თარგმნილ ფსევდონიმზე მიმართული A სამუშაო უნდა ჩავარდეს დახურულად. შემდეგ გატეხეთ ერთი გვირაბი და დაადასტურეთ, რომ სამუშაო ჩავარდება მხოლოდ ამ მოიჯარისთვის, სხვა მომხმარებლის იმავე ნომრიან ქვექსელზე დაუბრუნებლად. აღდგენაც უნდა შემოწმდეს, რადგან მოძველებულმა მარშრუტმა ან ქეშირებულმა სერთიფიკატებმა შეიძლება გადააჭარბოს გათიშვას.
არქიტექტურა შეიძლება იყოს გაერთიანებული მუშაკები იზოლირებული კონექტორებით, ან სრულიად განცალკევებული მოიჯარის რესურსები. უცვლელი იგივეა: დადასტურებული მოიჯარის კონტექსტი ირჩევს მარშრუტს და სერთიფიკატებს, და არც ერთი მარშრუტის ცვლილება არასდროს აძლევს აპლიკაციას ნებართვას მოიჯარეებს შორის.