Sådan dirigerer du SaaS-trafik til den rigtige kunde-VPN
Overlappende kundesubnet bryder delt routing. Vælg en isolationsmodel, bind hvert job til en verificeret tenant, og test kryds-tenant-stier før lancering.
En SaaS-platform forbinder ud til tolv kundenetværk, og to af disse kunder bruger begge 10.20.0.10 til deres primære database. En worker, der modtager den adresse i et job, har ingen måde at se, hvilken database jobbet mener, og en delt routingtabel sender den med glæde til den tunnel, præfikset peger på. Løsningen er ikke flere tunneller; den er at beslutte, hvor tenantidentitet kommer ind i stien, og hvilken isolationsmodel adresseplanen kræver. Tre betingelser afgør valget: om kundepræfikser overlapper, hvor langt en fejl kan sprede sig, og hvem der driver connectoren.
To kundedatabaser, én destinationsadresse
En IP-adresse er en placering, ikke en identitet. Anmodningen skal bære en tenant, som serveren har verificeret, og den tenant skal vælge netværkskonteksten, før destinationen slås op.
Når det ikke sker, er fejlen stille. Forbindelsen lykkes, forespørgslen kører, og svaret kommer fra den forkerte kundes database, fordi routingtabellen havde én post til 10.20.0.10. DNS gør det værre: et cachelagret navn, der blev opløst i tenant A's kontekst, kan genbruges af et job, der kører for tenant B. Intet i pakken skelner de to, så ingen mængde genforsøgslogik reparerer det.
Beslut isolationsmodellen først
Skriv de tre betingelser ned, før du sammenligner produkter. Overlap afgør, om ét adresserum overhovedet kan deles; blast radius afgør, om en routingfejl er en supportbillet eller et brud; operationelt ejerskab afgør, om du kan køre en connectorflåde per tenant.
| 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 |
Hvis præfikserne er forskellige, og politikken tillader et kontrolleret hub, er én Transit Gateway med routingtabeller per tenant gennemførlig. Attachment-association vælger den routingtabel, der bruges til trafik, der kommer ind fra det attachment, og propagation vælger, hvilke ruter der vises i en tabel. Et tenant-attachment, der kun er knyttet til sin egen tabel og kun propagaterer sine egne præfikser, når hubben og intet andet. Det er en routingbeslutning, og den forbliver kun korrekt, så længe ingen tilføjer en standardrute til den delte tabel.
Hvis præfikser overlapper, kan routing alene ikke adskille dem. Du har brug for enten en særskilt netværkskontekst per tenant eller en oversættelsesplan, der giver hver kundes rum en entydig betydning.
Hvad Transit Gateway-isolation egentlig betyder
Association og propagation er de to knapper, der betyder noget, og de er lette at forveksle. Association besvarer, hvilken tabel en pakke fra dette attachment slås op i; propagation besvarer, hvilke tabeller der lærer dette attachments ruter. Isolation kommer af at gøre begge tenantspecifikke, ikke af at oprette flere attachments.
Et standard all-to-all-opsætning er praktisk og er ikke isolation. Separate routingtabeller begrænser forbindelsen, men de giver ikke én uændret destinationsadresse to betydninger inden for samme routingkontekst. Hvis applikationen slår 10.20.0.10 op, før den kender tenanten, har routinglaget allerede mistet den information, det ville have brug for.
AWS tilføjede 23. oktober 2026 1:1-NAT på attachment-niveau til Transit Gateway og Cloud WAN, hvilket ændrer overlapssvaret for understøttede attachments. Transit Gateway NAT-dokumentationen beskriver statiske, statsløse IPv4-tilknytninger med lige præfikser og bevarede hostbits. Kontroller understøttede attachment-typer og regionale begrænsninger, før du designer ud fra det.
Bind jobbet til en verificeret tenant
Hvert job bør bære en serververificeret tenantidentitet, og den identitet bør vælge en forbindelsespost, som administratoren ejer. Posten angiver den godkendte netværkskontekst, tjenesteadressen, referencen til legitimationsoplysningerne og de operationer, der er tilladt der. En ubetroet anmodning må aldrig levere sin egen VPN-identifikator, gateway eller private mål, fordi et gyldigt login ikke er tilladelse til at undersøge hver tilsluttet kundes adresserum.
I et design med isolerede connectors går tenant A's arbejde til en A-specifik connector, der kører i A's VPC og kun kan nå A's godkendte ressourcer. Separate containere på én host skaber ikke den adskillelse af sig selv; netværksnavnerummene, ruterne og egress-politikken skal implementere den. Connectoren har også brug for tenantbegrænsede legitimationsoplysninger og køer, fordi en privat rute ikke begrænser en delt hemmelighed eller et delt arbejdselement. Poolede applikationsworkers er fine, så længe netværkskonteksten og legitimationsoplysningerne vælges per tenant, ikke per host.
Sundhedstjek bør angive tenanten og fasen: tunnel etableret, rute til stede og en rigtig tjenesteforespørgsel gennemført er tre forskellige signaler. Et samlet antal tunneller, der er oppe, vil skjule den ene kunde, hvis connector er i stykker.
Test de stier, der skal fejle
Kør tre tests før lancering. En tilladt A-operation skal lykkes, en tilladt B-operation skal lykkes, og et A-job, der bevidst er rettet mod Bs connector eller oversatte alias, skal fejle lukket. Bryd derefter én tunnel og bekræft, at jobbet kun fejler for den tenant, uden at falde tilbage til en anden kundes subnet med samme nummer. Gendannelse bør også testes, fordi en forældet rute eller cachelagrede legitimationsoplysninger kan overleve afbrydelsen.
Arkitekturen kan være poolede workers med isolerede connectors eller helt adskilte tenantressourcer. Invarianten er den samme: verificeret tenantkontekst vælger ruten og legitimationsoplysningerne, og ingen ruteændring giver nogensinde applikationstilladelse på tværs af tenants.