Kiel enkursigi SaaS-trafikon al la ĝusta klienta VPN
Interkovrantaj klientaj subretoj rompas komunan enkursigadon. Elektu izolmodelon, ligu ĉiun taskon al kontrolita luanto, kaj testu vojojn inter luantoj antaŭ lanĉo.
SaaS-platformo konektiĝas al dekdu klientaj retoj, kaj du el tiuj klientoj ambaŭ uzas 10.20.0.10 por sia ĉefa datumbazo. Laboranto, kiu ricevas tiun adreson en tasko, neniel povas scii, kiun datumbazon la tasko celas, kaj komuna enkursiga tabelo volonte sendos ĝin al tiu tunelo, al kiu montras la prefikso. La solvo ne estas pli da tuneloj; ĝi estas decidi, kie la identeco de la luanto eniras la vojon kaj kiun izolmodelon la adresplano postulas. Tri kondiĉoj decidas la elekton: ĉu klientaj prefiksoj interkovras, kiom malproksimen eraro povas disvastiĝi, kaj kiu funkciigas la konektilon.
Du klientaj datumbazoj, unu celadreso
IP-adreso estas loko, ne identeco. La peto devas porti luanton, kiun la servilo kontrolis, kaj tiu luanto devas elekti la retan kuntekston antaŭ ol la celo estas solvita.
Kiam tio ne okazas, la fiasko estas silenta. La konekto sukcesas, la konsulto ruliĝas, kaj la respondo venas el la datumbazo de la malĝusta kliento, ĉar la enkursiga tabelo havis unu eron por 10.20.0.10. DNS plimalbonigas ĝin: kaŝmemora nomo solvita en la kunteksto de luanto A povas esti reuzata de tasko ruliĝanta por luanto B. Nenio en la paketo distingas la du, do neniu kvanto da reprovlogiko riparas ĝin.
Unue decidu pri la izolmodelo
Skribu la tri kondiĉojn antaŭ ol kompari produktojn. Interkovro decidas, ĉu unu adresspaco entute povas esti dividita; la efekta radiuso decidas, ĉu enkursiga eraro estas subtena bileto aŭ sekureca rompo; operacia posedado decidas, ĉu vi povas funkciigi konektilan floton por ĉiu luanto.
| 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 |
Se la prefiksoj estas apartaj kaj la politiko permesas kontrolatan hubon, unu Transit Gateway kun enkursigaj tabeloj por ĉiu luanto estas farebla. La alliga asociado elektas la enkursigan tabelon uzatan por trafiko eniranta el tiu alligo, kaj la disvastigo elektas, kiuj vojoj aperas en tabelo. Luanta alligo asociita nur kun sia propra tabelo kaj disvastiganta nur siajn proprajn prefiksojn atingas la hubon kaj nenion alian. Tio estas enkursiga decido, kaj ĝi restas ĝusta nur dum neniu aldonas defaŭltan vojon al la komuna tabelo.
Se la prefiksoj interkovras, enkursigado sola ne povas apartigi ilin. Vi bezonas aŭ apartan retan kuntekston por ĉiu luanto aŭ tradukplanon, kiu donas al la spaco de ĉiu kliento neambiguan signifon.
Kion efektive signifas izolado de Transit Gateway
Asociado kaj disvastigo estas la du gravaj butonoj, kaj facile konfuzeblaj. Asociado respondas, en kiu tabelo paketo el tiu alligo estas serĉata; disvastigo respondas, kiuj tabeloj lernas la vojojn de tiu alligo. Izolado venas de tio, ke ambaŭ fariĝas luantospecifaj, ne de kreado de pli da alligoj.
Defaŭlta ĉiuj-al-ĉiuj agordo estas oportuna kaj ne estas izolado. Apartaj enkursigaj tabeloj limigas konektecon, sed ili ne donas al unu neŝanĝita celadreso du signifojn en la sama enkursiga kunteksto. Se la aplikaĵo solvas 10.20.0.10 antaŭ ol ĝi scias la luanton, la enkursiga tavolo jam perdis la informon, kiun ĝi bezonus.
AWS aldonis la 23-an de oktobro 2026 NAT 1:1 je alliga nivelo por Transit Gateway kaj Cloud WAN, kio ŝanĝas la interkovran respondon por subtenataj alligoj. La dokumentaro pri Transit Gateway NAT priskribas statikajn, senstatujn IPv4-mapojn de egala prefikso kun konservitaj gastigantaj bitoj. Kontrolu subtenatajn alligajn tipojn kaj regionajn limigojn antaŭ ol desegni ĉirkaŭ tio.
Ligu la taskon al kontrolita luanto
Ĉiu tasko devus porti servile kontrolitan luantan identecon, kaj tiu identeco devus elekti administrantan konektan rikordon. La rikordo nomas la aprobitan retan kuntekston, la servadreson, la referencon al akreditaĵoj, kaj la permesitajn operaciojn tie. Nefidinda peto neniam rajtas liveri sian propran VPN-identigilon, pordegon aŭ privatan celon, ĉar valida ensaluto ne estas permeso sondi la adresspacon de ĉiu konektita kliento.
En dezajno kun izolitaj konektiloj, la laboro de luanto A iras al konektilo specifa por A, kiu ruliĝas en la VPC de A kaj povas atingi nur la aprobitajn rimedojn de A. Apartaj ujoj sur unu gastiganto mem ne kreas tiun apartigon; la retaj nomspacoj, vojoj kaj elira politiko devas efektivigi ĝin. La konektilo ankaŭ bezonas luantoskopajn akreditaĵojn kaj atendovicojn, ĉar privata vojo ne limigas komunan sekreton aŭ komunan laboreron. Kunigitaj aplikaĵaj laborantoj estas en ordo tiom longe, kiom la reta kunteksto kaj akreditaĵoj estas elektitaj por ĉiu luanto, ne por ĉiu gastiganto.
Sanaj kontroloj devus nomi la luanton kaj la stadion: tunelo establita, vojo ĉeestanta kaj sukcesa reala servopeto estas tri malsamaj signaloj. Suma nombro de tuneloj, kiuj estas aktivaj, kaŝos la solan klienton, kies konektilo estas difektita.
Testu la vojojn, kiuj devas fiaski
Rulu tri testojn antaŭ lanĉo. Permesita operacio A devas sukcesi, permesita operacio B devas sukcesi, kaj tasko A intence celanta la konektilon de B aŭ ĝian tradukitan alinomon devas fiaski fermite. Poste rompu unu tunelon kaj konfirmu, ke la tasko fiaskas nur por tiu luanto, sen fali al subreto de alia kliento kun la sama numero. Restarigo ankaŭ devus esti testita, ĉar malnova vojo aŭ kaŝmemoraj akreditaĵoj povas postvivi la interrompon.
La arkitekturo povas esti kunigitaj laborantoj kun izolitaj konektiloj aŭ tute apartigitaj luantaj rimedoj. La invarianto estas la sama: kontrolita luanta kunteksto elektas la vojon kaj la akreditaĵojn, kaj neniu vojŝanĝo iam donas aplikaĵan permeson trans luantoj.