Kako usmeriti promet SaaS do pravega VPN stranke
Prekrivajoče se stranke podomrežja lomijo skupno usmerjanje. Izberite model izolacije, vsako opravilo povežite s preverjenim najemnikom in pred zagonom preizkusite poti med najemniki.
Platforma SaaS se povezuje z dvanajstimi omrežji strank, in dve od teh strank uporabljata 10.20.0.10 za svojo primarno zbirko podatkov. Delavec, ki v opravilu prejme ta naslov, ne more ugotoviti, katero zbirko podatkov opravilo misli, in skupna usmerjevalna tabela ga bo z veseljem poslala v tunel, na katerega kaže predpona. Rešitev ni več tunelov; rešitev je odločitev, kje identiteta najemnika vstopi na pot in kateri model izolacije zahteva načrt naslovov. Trije pogoji odločajo o izbiri: ali se predpone strank prekrivajo, kako daleč se lahko razširi napaka in kdo upravlja konektor.
Dve zbirki podatkov strank, en ciljni naslov
Naslov IP je lokacija, ne identiteta. Zahteva mora nositi najemnika, ki ga je strežnik preveril, in ta najemnik mora izbrati omrežni kontekst, preden se cilj razreši.
Ko se to ne zgodi, je napaka tiha. Povezava uspe, poizvedba se izvede, in odgovor pride iz zbirke podatkov napačne stranke, ker je imela usmerjevalna tabela en vnos za 10.20.0.10. DNS to poslabša: predpomnjeno ime, razrešeno v kontekstu najemnika A, lahko znova uporabi opravilo, ki teče za najemnika B. Nič v paketu ne razlikuje obeh, zato nobena logika ponovnih poskusov tega ne popravi.
Najprej se odločite o modelu izolacije
Zapišite tri pogoje, preden primerjate izdelke. Prekrivanje odloči, ali je en prostor naslovov sploh mogoče deliti; polmer učinka odloči, ali je usmerjevalna napaka podporni listek ali kršitev; operativno lastništvo odloči, ali lahko upravljate floto konektorjev za vsakega najemnika.
| 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 |
Če so predpone različne in politika dovoljuje nadzorovano vozlišče, je en Transit Gateway s tabelami usmerjanja za vsakega najemnika izvedljiv. Povezava pripetka izbere tabelo usmerjanja, ki se uporablja za promet, ki vstopa s tega pripetka, in razširjanje izbere, katere poti se pojavijo v tabeli. Pripetek najemnika, povezan le z lastno tabelo in ki razširja le lastne predpone, doseže vozlišče in nič drugega. To je odločitev o usmerjanju in ostane pravilna le, dokler nihče v skupno tabelo ne doda privzete poti.
Če se predpone prekrivajo, samo usmerjanje jih ne more ločiti. Potrebujete bodisi ločen omrežni kontekst za vsakega najemnika bodisi načrt prevajanja, ki daje prostoru vsake stranke nedvoumen pomen.
Kaj izolacija Transit Gateway v resnici pomeni
Povezava in razširjanje sta dva pomembna gumba in ju je lahko zamenjati. Povezava odgovarja, v kateri tabeli se išče paket s tega pripetka; razširjanje odgovarja, katere tabele se naučijo poti tega pripetka. Izolacija izhaja iz tega, da oboje naredite specifično za najemnika, ne iz ustvarjanja več pripetkov.
Privzeta nastavitev vsi-proti-vsem je priročna in ni izolacija. Ločene tabele usmerjanja omejujejo povezljivost, vendar enemu nespremenjenemu ciljnemu naslovu ne dajo dveh pomenov v istem kontekstu usmerjanja. Če aplikacija razreši 10.20.0.10, preden pozna najemnika, je usmerjevalna plast že izgubila potrebno informacijo.
AWS je 23. oktobra 2026 dodala NAT 1:1 na ravni pripetka za Transit Gateway in Cloud WAN, kar spremeni odgovor o prekrivanju za podprte pripetke. Dokumentacija Transit Gateway NAT opisuje statične, brezstanjske preslikave IPv4 z enako predpono in ohranjenimi biti gostitelja. Pred načrtovanjem okoli tega preverite podprte vrste pripetkov in regionalne omejitve.
Povežite opravilo s preverjenim najemnikom
Vsako opravilo mora nositi identiteto najemnika, ki jo je preveril strežnik, in ta identiteta mora izbrati zapis povezave v lasti skrbnika. Zapis navaja odobreni omrežni kontekst, naslov storitve, sklic na poverilnice in dovoljene operacije. Nezaupanja vredna zahteva nikoli ne sme zagotoviti lastnega identifikatorja VPN, prehoda ali zasebnega cilja, ker veljavna prijava ni dovoljenje za preiskovanje naslovnega prostora vsake povezane stranke.
V zasnovi z izoliranimi konektorji gre delo najemnika A h konektorju, specifičnemu za A, ki teče v VPC najemnika A in lahko doseže le odobrene vire A. Ločeni vsebniki na enem gostitelju te ločitve ne ustvarijo sami; omrežni imenski prostori, poti in politika izhoda jo morajo izvesti. Konektor potrebuje tudi poverilnice in čakalne vrste v obsegu najemnika, ker zasebna pot ne omejuje skupne skrivnosti ali skupne delovne postavke. Združeni delavci aplikacije so v redu, dokler se omrežni kontekst in poverilnice izbereta za vsakega najemnika, ne za vsakega gostitelja.
Preverjanja stanja morajo navesti najemnika in fazo: tunel vzpostavljen, pot prisotna in uspešna resnična zahteva storitve so trije različni signali. Zbirno število tunelov, ki so aktivni, bo skrilo edino stranko, katere konektor je pokvarjen.
Preizkusite poti, ki morajo odpovedati
Pred zagonom izvedite tri teste. Dovoljena operacija A mora uspeti, dovoljena operacija B mora uspeti, in opravilo A, namerno usmerjeno na konektor B ali njegov prevedeni vzdevek, mora odpovedati zaprto. Nato prekinite en tunel in potrdite, da opravilo odpove samo za tega najemnika, brez padca v podomrežje z isto številko druge stranke. Preizkusiti je treba tudi obnovitev, ker lahko zastarela pot ali predpomnjene poverilnice preživijo izpad.
Arhitektura je lahko združeni delavci z izoliranimi konektorji ali popolnoma ločeni viri najemnikov. Invarianta je enaka: preverjeni kontekst najemnika izbere pot in poverilnice, in nobena sprememba poti nikoli ne podeli aplikaciji dovoljenja med najemniki.