Hogyan irányítsuk a SaaS-forgalmat a megfelelő ügyfél-VPN-hez
Az átfedő ügyfél-alhálózatok megtörik a megosztott forgalomirányítást. Válasszon izolációs modellt, kössön minden feladatot ellenőrzött bérlőhöz, és indítás előtt tesztelje a bérlők közötti útvonalakat.
Egy SaaS-platform egy tucat ügyfélhálózathoz kapcsolódik, és ezek közül két ügyfél is a 10.20.0.10 címet használja elsődleges adatbázisához. Az a worker, amely egy feladatban ezt a címet kapja, semmilyen módon nem tudja megállapítani, melyik adatbázisra gondol a feladat, és a megosztott forgalomirányítási tábla készségesen ahhoz az alagúthoz küldi, amelyre az előtag mutat. A megoldás nem több alagút; hanem annak eldöntése, hol lép be a bérlő identitása az útvonalba, és milyen izolációs modellt igényel a címterv. Három feltétel dönti el a választást: átfednek-e az ügyfél-előtagok, milyen messzire terjedhet egy hiba, és ki üzemelteti a csatlakozót.
Két ügyfél-adatbázis, egy célcím
Az IP-cím hely, nem identitás. A kérésnek olyan bérlőt kell hordoznia, amelyet a kiszolgáló ellenőrzött, és ennek a bérlőnek ki kell választania a hálózati környezetet, mielőtt a cél feloldódik.
Amikor ez nem történik meg, a hiba csendes. A kapcsolat létrejön, a lekérdezés lefut, és a válasz a rossz ügyfél adatbázisából érkezik, mert a forgalomirányítási táblában egyetlen bejegyzés volt a 10.20.0.10 címhez. A DNS tovább rontja: egy gyorsítótárazott név, amely az A bérlő környezetében oldódott fel, újra felhasználható egy B bérlő számára futó feladat által. Semmi a csomagban nem különbözteti meg a kettőt, ezért semmilyen újrapróbálkozási logika nem javítja meg.
Először az izolációs modellről döntsön
Írja le a három feltételt, mielőtt termékeket hasonlít össze. Az átfedés eldönti, hogy egyáltalán megosztható-e egy címtér; a hatássugár eldönti, hogy a forgalomirányítási hiba támogatási jegy vagy incidens-e; az üzemeltetési tulajdon eldönti, hogy futtathat-e csatlakozóflottát bérlőnként.
| 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 |
Ha az előtagok különbözőek, és a szabályzat engedélyez egy felügyelt központot, egy Transit Gateway bérlőnkénti forgalomirányítási táblákkal járható út. A csatolás-hozzárendelés kiválasztja azt a forgalomirányítási táblát, amelyet az adott csatolásból érkező forgalom használ, a terjesztés pedig kiválasztja, mely útvonalak jelennek meg egy táblában. Egy bérlői csatolás, amely csak a saját táblájához van rendelve, és csak a saját előtagjait terjeszti, eléri a központot és semmi mást. Ez forgalomirányítási döntés, és csak addig marad helyes, amíg senki nem ad hozzá alapértelmezett útvonalat a megosztott táblához.
Ha az előtagok átfednek, a forgalomirányítás önmagában nem tudja szétválasztani őket. Vagy külön hálózati környezetre van szüksége bérlőnként, vagy olyan fordítási tervre, amely egyértelmű jelentést ad minden ügyfél terének.
Mit jelent valójában a Transit Gateway izolációja
A hozzárendelés és a terjesztés a két fontos kapcsoló, és könnyű összekeverni őket. A hozzárendelés megválaszolja, melyik táblában keresik az ebből a csatolásból érkező csomagot; a terjesztés megválaszolja, mely táblák tanulják meg a csatolás útvonalait. Az izoláció abból ered, hogy mindkettőt bérlőspecifikussá tesszük, nem abból, hogy több csatolást hozunk létre.
Az alapértelmezett mindenki-mindenkivel beállítás kényelmes, és nem izoláció. A külön forgalomirányítási táblák korlátozzák az elérhetőséget, de nem adnak két jelentést egy változatlan célcímnek ugyanazon forgalomirányítási környezeten belül. Ha az alkalmazás a bérlő ismerete előtt oldja fel a 10.20.0.10 címet, a forgalomirányítási réteg már elvesztette a szükséges információt.
Az AWS 2026. október 23-án hozzáadta a csatolásszintű 1:1 NAT-ot a Transit Gatewayhez és a Cloud WANhez, ami megváltoztatja az átfedésre adott választ a támogatott csatolások esetében. A Transit Gateway NAT dokumentációja statikus, állapotmentes, azonos előtagú IPv4-leképezéseket ír le, a gazdabitek megőrzésével. A köré tervezés előtt ellenőrizze a támogatott csatolástípusokat és a regionális korlátokat.
Kösse a feladatot ellenőrzött bérlőhöz
Minden feladatnak kiszolgáló által ellenőrzött bérlőidentitást kell hordoznia, és ennek az identitásnak adminisztrátor tulajdonában lévő kapcsolati rekordot kell választania. A rekord megnevezi a jóváhagyott hálózati környezetet, a szolgáltatás címét, a hitelesítő adatok hivatkozását és az ott engedélyezett műveleteket. Egy nem megbízható kérés soha nem adhatja meg a saját VPN-azonosítóját, átjáróját vagy privát célját, mert az érvényes bejelentkezés nem engedély minden csatlakoztatott ügyfél címtartományának vizsgálatára.
Izolált csatlakozós kialakításban az A bérlő munkája egy A-specifikus csatlakozóhoz kerül, amely az A VPC-jében fut, és csak az A jóváhagyott erőforrásait érheti el. Az egy gazdagépen lévő külön konténerek önmagukban nem hozzák létre ezt a szétválasztást; a hálózati névtereknek, az útvonalaknak és a kimenő forgalom szabályzatának kell megvalósítania. A csatlakozónak bérlőre korlátozott hitelesítő adatokra és sorokra is szüksége van, mert egy privát útvonal nem korlátoz egy megosztott titkot vagy egy megosztott munkaelemet. Az egyesített alkalmazás-workerek rendben vannak, amíg a hálózati környezetet és a hitelesítő adatokat bérlőnként választjuk, nem gazdagépenként.
Az állapotellenőrzéseknek meg kell nevezniük a bérlőt és a szakaszt: az alagút létrejötte, az útvonal megléte és egy valódi szolgáltatáskérés sikere három különböző jelzés. Az aktív alagutak összesített száma elrejti azt az egyetlen ügyfelet, amelynek a csatlakozója tönkrement.
Tesztelje azokat az útvonalakat, amelyeknek meg kell hiúsulniuk
Az indítás előtt futtasson három tesztet. Egy engedélyezett A-műveletnek sikerülnie kell, egy engedélyezett B-műveletnek sikerülnie kell, és egy szándékosan B csatlakozójára vagy lefordított aliasára irányított A-feladatnak zártan meg kell hiúsulnia. Ezután szakítson meg egy alagutat, és erősítse meg, hogy a feladat csak ennél a bérlőnél hiúsul meg, és nem esik vissza egy másik ügyfél azonos számú alhálózatára. A helyreállítást is tesztelni kell, mert egy elavult útvonal vagy gyorsítótárazott hitelesítő adat túlélheti a kiesést.
Az architektúra lehet egyesített worker izolált csatlakozókkal, vagy teljesen elkülönített bérlői erőforrás. Az invariáns ugyanaz: az ellenőrzött bérlői környezet választja ki az útvonalat és a hitelesítő adatokat, és semmilyen útvonalváltozás nem ad soha alkalmazásengedélyt a bérlők között.