Slik ruter du SaaS-trafikk til riktig kunde-VPN
Overlappende kundenett bryter delt ruting. Velg en isolasjonsmodell, bind hver jobb til en verifisert leietaker, og test tverrleietaker-stier før lansering.
En SaaS-plattform kobler seg ut til tolv kundenettverk, og to av disse kundene bruker begge 10.20.0.10 til sin primære database. En worker som mottar den adressen i en jobb, har ingen måte å vite hvilken database jobben mener, og en delt rutingtabell sender den gjerne til den tunnelen prefikset peker på. Løsningen er ikke flere tunneler; den er å bestemme hvor leietakeridentiteten kommer inn i stien og hvilken isolasjonsmodell adresseplanen krever. Tre forhold avgjør valget: om kundeprefiksene overlapper, hvor langt en feil kan spre seg, og hvem som drifter connectoren.
To kundedatabaser, én destinasjonsadresse
En IP-adresse er et sted, ikke en identitet. Forespørselen må bære en leietaker som serveren har verifisert, og den leietakeren må velge nettverkskonteksten før destinasjonen løses opp.
Når det ikke skjer, er feilen stille. Tilkoblingen lykkes, spørringen kjøres, og svaret kommer fra feil kundes database fordi rutingtabellen hadde én oppføring for 10.20.0.10. DNS gjør det verre: et bufret navn som ble løst opp i leietaker A sin kontekst, kan gjenbrukes av en jobb som kjører for leietaker B. Ingenting i pakken skiller de to, så ingen mengde gjenforsøkslogikk reparerer det.
Bestem isolasjonsmodellen først
Skriv ned de tre forholdene før du sammenligner produkter. Overlapp avgjør om ett adresserom kan deles i det hele tatt; blast radius avgjør om en rutingfeil er en støttebillett eller et brudd; operativt eierskap avgjør om du kan drifte en connectorflåte per leietaker.
| 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 prefiksene er forskjellige og policyen tillater et kontrollert hub, er én Transit Gateway med rutingtabeller per leietaker gjennomførbart. Attachment-tilknytningen velger rutingtabellen som brukes for trafikk som kommer inn fra det attachmentet, og propageringen velger hvilke ruter som vises i en tabell. Et leietaker-attachment som bare er knyttet til sin egen tabell og bare propagerer sine egne prefikser, når huben og ingenting annet. Det er en rutingbeslutning, og den forblir bare riktig så lenge ingen legger til en standardrute i den delte tabellen.
Hvis prefiksene overlapper, kan ruting alene ikke skille dem. Du trenger enten en egen nettverkskontekst per leietaker eller en oversettelsesplan som gir hver kundes rom en entydig betydning.
Hva Transit Gateway-isolasjon egentlig betyr
Tilknytning og propagering er de to knottene som betyr noe, og de er lette å forveksle. Tilknytning svarer på hvilken tabell en pakke fra dette attachmentet slås opp i; propagering svarer på hvilke tabeller som lærer attachmentets ruter. Isolasjon kommer av å gjøre begge leietakerspesifikke, ikke av å opprette flere attachments.
Et standard alle-til-alle-oppsett er praktisk og er ikke isolasjon. Separate rutingtabeller begrenser tilkoblingen, men de gir ikke én uendret destinasjonsadresse to betydninger innenfor samme rutingkontekst. Hvis applikasjonen løser opp 10.20.0.10 før den kjenner leietakeren, har rutinglaget allerede mistet informasjonen det ville trengt.
AWS la til 23. oktober 2026 1:1-NAT på attachment-nivå for Transit Gateway og Cloud WAN, noe som endrer overlappsvaret for støttede attachments. Transit Gateway NAT-dokumentasjonen beskriver statiske, tilstandsløse IPv4-tilordninger med likt prefiks og bevarte vertsbits. Sjekk støttede attachment-typer og regionale begrensninger før du designer rundt det.
Bind jobben til en verifisert leietaker
Hver jobb bør bære en serververifisert leietakeridentitet, og den identiteten bør velge en tilkoblingspost som administratoren eier. Posten navngir den godkjente nettverkskonteksten, tjenesteadressen, referansen til legitimasjonen og operasjonene som er tillatt der. En ubetrodd forespørsel må aldri levere sin egen VPN-identifikator, gateway eller private mål, fordi en gyldig innlogging ikke er tillatelse til å undersøke adresserommet til hver tilkoblet kunde.
I et design med isolerte connectore går leietaker A sin jobb til en A-spesifikk connector som kjører i A sin VPC og bare kan nå A sine godkjente ressurser. Separate containere på én vert skaper ikke den separasjonen av seg selv; nettverksnavnerommene, rutene og egress-policyen må implementere den. Connectoren trenger også leietakerbegrensede legitimasjoner og køer, siden en privat rute ikke begrenser en delt hemmelighet eller et delt arbeidselement. Samlede applikasjonsworkere er greit så lenge nettverkskonteksten og legitimasjonen velges per leietaker, ikke per vert.
Helsesjekker bør navngi leietakeren og fasen: tunnel etablert, rute til stede og en reell tjenesteforespørsel som lyktes er tre forskjellige signaler. Et samlet antall tunneler som er oppe, vil skjule den ene kunden hvis connector er ødelagt.
Test stiene som må feile
Kjør tre tester før lansering. En tillatt A-operasjon må lykkes, en tillatt B-operasjon må lykkes, og en A-jobb som med vilje er rettet mot B sin connector eller oversatte alias, må feile lukket. Bryt deretter én tunnel og bekreft at jobben feiler bare for den leietakeren, uten å falle tilbake til en annen kundes subnett med samme nummer. Gjenoppretting bør også testes, fordi en utdatert rute eller bufret legitimasjon kan overleve avbruddet.
Arkitekturen kan være samlede workere med isolerte connectore, eller helt adskilte leietakerressurser. Invarianten er den samme: verifisert leietakerkontekst velger ruten og legitimasjonen, og ingen ruteendring gir noen gang applikasjonstillatelse på tvers av leietakere.