Hoe om SaaS-verkeer na die regte kliënt-VPN te lei

'n SaaS-platform maak verbinding met 'n dosyn kliëntnetwerke, en twee van daardie kliënte gebruik albei 10.20.0.10 vir hul primêre databasis. 'n Werkproses wat daardie adres in 'n taak ontvang, het geen manier om te sien watter databasis die taak bedoel nie, en 'n gedeelde roetertabel sal dit graag na watter tonnel ook al die voorvoegsel wys, stuur. Die oplossing is nie meer tonnels nie; dit is om te besluit waar huurderidentiteit die pad binnekom en watter isolasiemodel die adresplan vereis. Drie voorwaardes beslis die keuse: of kliëntvoorvoegsels oorvleuel, hoe ver 'n fout kan versprei, en wie die konnektor bedryf.

Twee kliëntdatabasisse, een bestemmingsadres

'n IP-adres is 'n ligging, nie 'n identiteit nie. Die versoek moet 'n huurder dra wat die bediener geverifieer het, en daardie huurder moet die netwerkkonteks kies voordat die bestemming opgelos word.

Wanneer dit nie gebeur nie, is die fout stil. Die verbinding slaag, die navraag loop, en die antwoord kom uit die verkeerde kliënt se databasis omdat die roetertabel een inskrywing vir 10.20.0.10 gehad het. DNS maak dit erger: 'n gekaste naam wat in huurder A se konteks opgelos is, kan weer deur 'n taak vir huurder B gebruik word. Niks in die pakket onderskei die twee nie, so geen hoeveelheid herprobeerlogika herstel dit nie.

Besluit eerste oor die isolasiemodel

Skryf die drie voorwaardes neer voordat jy produkte vergelyk. Oorvleueling besluit of een adresruimte hoegenaamd gedeel kan word; die impakradius besluit of 'n roeteringsfout 'n ondersteuningskaartjie of 'n oortreding is; operasionele eienaarskap besluit of jy 'n konnektorvloot per huurder kan bedryf.

As voorvoegsels onderskeibaar is en die beleid 'n beheerde spilpunt toelaat, is een Transit Gateway met roetertabelle per huurder werkbaar. Aanhegtingassosiasie kies die roetertabel wat vir verkeer vanaf daardie aanhegting gebruik word, en propagasie kies watter roetes in 'n tabel verskyn. 'n Huurderaanhegting wat slegs met sy eie tabel geassosieer is en slegs sy eie voorvoegsels propageer, bereik die spilpunt en niks anders nie. Dit is 'n roeteringsbeslissing, en dit bly korrek net solank niemand 'n verstekroete by die gedeelde tabel voeg nie.

As voorvoegsels oorvleuel, kan roetering alleen hulle nie skei nie. Jy het óf 'n aparte netwerkkonteks per huurder óf 'n vertaalplan nodig wat elke kliënt se ruimte 'n ondubbelsinnige betekenis gee.

Wat Transit Gateway-isolasie werklik beteken

Assosiasie en propagasie is die twee knoppies wat saak maak, en hulle is maklik om te verwar. Assosiasie antwoord in watter tabel 'n pakket van hierdie aanhegting opgesoek word; propagasie antwoord watter tabelle hierdie aanhegting se roetes leer. Isolasie kom daaruit om albei huurderspesifiek te maak, nie uit die skep van meer aanhegtings nie.

'n Verstek alles-na-alles-opstelling is gerieflik en is nie isolasie nie. Aparte roetertabelle beperk verbinding, maar hulle gee nie een onveranderde bestemmingsadres twee betekenisse binne dieselfde roeteringskonteks nie. As die toepassing 10.20.0.10 oplos voordat dit die huurder ken, het die roeteringslaag reeds die inligting verloor wat dit sou nodig hê.

AWS het op 23 Oktober 2026 aanhegtingvlak-1:1-NAT vir Transit Gateway en Cloud WAN bygevoeg, wat die oorvleuelingsantwoord vir ondersteunde aanhegtings verander. Die Transit Gateway NAT-dokumentasie beskryf statiese, toestandlose gelyke-voorvoegsel-IPv4-karterings met gasheerbits behoue. Kontroleer ondersteunde aanhegtingtipes en streeksbeperkings voordat jy rondom dit ontwerp.

Bind die taak aan 'n geverifieerde huurder

Elke taak moet 'n bediener-geverifieerde huurderidentiteit dra, en daardie identiteit moet 'n administrateur-bestuurde verbindingsrekord kies. Die rekord noem die goedgekeurde netwerkkonteks, die diensadres, die geloofsbrieweverwysing en die bewerkings wat daar toegelaat word. 'n Onbetroubare versoek mag nooit sy eie VPN-identifiseerder, gateway of private teiken verskaf nie, want 'n geldige aanmelding is nie toestemming om elke gekoppelde kliënt se adresruimte te ondersoek nie.

In 'n ontwerp met geïsoleerde konnektors gaan huurder A se werk na 'n A-spesifieke konnektor wat in A se VPC loop en slegs A se goedgekeurde hulpbronne kan bereik. Aparte houers op een gasheer skep nie daardie skeiding vanself nie; die netwerknaamruimtes, roetes en uitgangsbeleid moet dit implementeer. Die konnektor het ook huurderbeperkte geloofsbriewe en waglyste nodig, want 'n private roete beperk nie 'n gedeelde geheim of 'n gedeelde werkitem nie. Gepoelde toepassingswerkers is reg solank die netwerkkonteks en geloofsbriewe per huurder gekies word, nie per gasheer nie.

Gesondheidskontroles moet die huurder en die fase noem: tonnel gevestig, roete teenwoordig en 'n werklike diensversoek wat geslaag het, is drie verskillende seine. 'n Saamgetelde telling van tonnels wat op is, sal die een kliënt verberg wie se konnektor stukkend is.

Toets die paaie wat moet misluk

Voer drie toetse uit voor die bekendstelling. 'n Toegelate A-bewerking moet slaag, 'n toegelate B-bewerking moet slaag, en 'n A-taak wat doelbewus op B se konnektor of vertaalde alias gemik is, moet gesluit faal. Breek dan een tonnel en bevestig dat die taak slegs vir daardie huurder misluk, sonder om na 'n ander kliënt se selfde-genommerde subnet terug te val. Herstel moet ook getoets word, want 'n verouderde roete of gekaste geloofsbrief kan die onderbreking oorleef.

Die argitektuur kan gepoelde werkers met geïsoleerde konnektors wees, of heeltemal geskeide huurderhulpbronne. Die onveranderlike is dieselfde: geverifieerde huurderkonteks kies die roete en die geloofsbriewe, en geen roeteverandering verleen ooit toepassingstoestemming oor huurders heen nie.