Slik ruter du SaaS-trafikk til rett kunde-VPN
Overlappande kundenett bryt delt ruting. Vel ein isolasjonsmodell, bind kvar jobb til ein verifisert leigetakar, og test tverrleigetakar-stiar før lansering.
Ein SaaS-plattform koplar seg ut til tolv kundenettverk, og to av desse kundane brukar begge 10.20.0.10 til den primære databasen sin. Ein worker som får den adressa i ein jobb, har ingen måte å vite kva database jobben meiner, og ein delt rutingtabell sender han gjerne til den tunnelen prefikset peikar på. Løysinga er ikkje fleire tunnelar; ho er å bestemme kvar leigetakaridentiteten kjem inn i stien og kva isolasjonsmodell adresseplanen krev. Tre vilkår avgjer valet: om kundeprefiksa overlappar, kor langt ein feil kan spreie seg, og kven som driftar connectoren.
To kundedatabasar, éi destinasjonsadresse
Ei IP-adresse er ein stad, ikkje ein identitet. Førespurnaden må bera ein leigetakar som tenaren har verifisert, og den leigetakaren må velje nettverkskonteksten før destinasjonen blir løyst opp.
Når det ikkje skjer, er feilen stille. Tilkoplinga lukkast, spørjinga køyrer, og svaret kjem frå databasen til feil kunde fordi rutingtabellen hadde éi oppføring for 10.20.0.10. DNS gjer det verre: eit bufra namn som vart løyst opp i konteksten til leigetakar A, kan bli brukt på nytt av ein jobb som køyrer for leigetakar B. Ingenting i pakken skil dei to, så ingen mengd gjenforskingslogikk reparerer det.
Bestem isolasjonsmodellen først
Skriv ned dei tre vilkåra før du samanliknar produkt. Overlapp avgjer om eitt adresserom kan delast i det heile; blast radius avgjer om ein rutingfeil er ein støttebillett eller eit brot; operativt eigarskap avgjer om du kan drifte ein connectorflåte per leigetakar.
| 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 |
Viss prefiksa er ulike og policyen tillèt eit kontrollert hub, er éin Transit Gateway med rutingtabellar per leigetakar gjennomførbart. Attachment-tilknytinga vel rutingtabellen som blir brukt for trafikk som kjem inn frå det attachmentet, og propageringa vel kva ruter som blir viste i ein tabell. Eit leigetakar-attachment som berre er knytt til sin eigen tabell og berre propagerer sine eigne prefiks, når huben og ingenting anna. Det er ei rutingavgjerd, og ho blir berre verande rett så lenge ingen legg til ei standardrute i den delte tabellen.
Viss prefiksa overlappar, kan ruting åleine ikkje skilje dei. Du treng anten ein eigen nettverkskontekst per leigetakar eller ein omsetjingsplan som gir rommet til kvar kunde ei eintydig meining.
Kva Transit Gateway-isolasjon eigentleg betyr
Tilknyting og propagering er dei to knottane som betyr noko, og dei er lette å forveksle. Tilknytinga svarar på kva tabell ein pakke frå dette attachmentet blir slått opp i; propageringa svarar på kva tabellar som lærer rutene til attachmentet. Isolasjon kjem av å gjere begge leigetakarspecifikke, ikkje av å opprette fleire attachments.
Eit standard alle-til-alle-oppsett er praktisk og er ikkje isolasjon. Separate rutingtabellar avgrensar tilkoplinga, men dei gir ikkje éi uendra destinasjonsadresse to meiningar innanfor same rutingkontekst. Viss applikasjonen løyser opp 10.20.0.10 før han kjenner leigetakaren, har rutinglaget allereie mista informasjonen det ville trengt.
AWS la til 23. oktober 2026 1:1-NAT på attachment-nivå for Transit Gateway og Cloud WAN, noko som endrar overlappssvaret for støtta attachments. Transit Gateway NAT-dokumentasjonen skildrar statiske, tilstandslause IPv4-tilordningar med likt prefiks og verna vertsbitar. Sjekk støtta attachment-typar og regionale avgrensingar før du designar rundt det.
Bind jobben til ein verifisert leigetakar
Kvar jobb bør bera ein serververifisert leigetakaridentitet, og den identiteten bør velje ein tilkoplingspost som administratoren eig. Posten namngir den godkjende nettverkskonteksten, tenesteadressa, referansen til legitimasjonen og operasjonane som er tillatne der. Ein ubetrudd førespurnad må aldri levere sin eigen VPN-identifikator, gateway eller private mål, fordi ei gyldig innlogging ikkje er løyve til å granske adresserommet til kvar tilkopla kunde.
I eit design med isolerte connectore går jobben til leigetakar A til ein A-spesifikk connector som køyrer i VPC-en til A og berre kan nå dei godkjende ressursane til A. Separate containerar på éin vert skaper ikkje den separasjonen av seg sjølv; nettverksnamneromma, rutene og egress-policyen må implementere han. Connectoren treng òg leigetakarbegrensa legitimasjon og køar, sidan ei privat rute ikkje avgrensar ein delt hemmelegheit eller eit delt arbeidselement. Samla applikasjonsworkarar er greitt så lenge nettverkskonteksten og legitimasjonen blir valde per leigetakar, ikkje per vert.
Helsesjekkar bør namngi leigetakaren og fasen: tunnel etablert, rute til stades og ein reell tenesteførespurnad som lukkast er tre ulike signal. Eit samla tal på tunnelar som er oppe, vil skjule den eine kunden der connectoren er øydelagd.
Test stiane som må feile
Køyr tre testar før lansering. Ein tillaten A-operasjon må lukkast, ein tillaten B-operasjon må lukkast, og ein A-jobb som med vilje er retta mot connectoren til B eller det omsette aliaset hans, må feile lukka. Bryt deretter éin tunnel og stadfest at jobben feilar berre for den leigetakaren, utan å falle tilbake til eit anna kundes subnett med same nummer. Gjenoppretting bør òg testast, fordi ei utdatert rute eller bufra legitimasjon kan overleve avbrotet.
Arkitekturen kan vere samla workarar med isolerte connectore, eller heilt åtskilde leigetakarressursar. Invarianten er den same: verifisert leigetakarkontekst vel ruta og legitimasjonen, og inga ruteendring gir nokon gong applikasjonstilgang på tvers av leigetakarar.