Så dirigerar du SaaS-trafik till rätt kund-VPN
Överlappande kundsubnät bryter delad routing. Välj en isolationsmodell, bind varje jobb till en verifierad tenant och testa vägar mellan tenants före lansering.
En SaaS-plattform ansluter ut till tolv kundnätverk, och två av dessa kunder använder båda 10.20.0.10 för sin primära databas. En worker som får den adressen i ett jobb har inget sätt att veta vilken databas jobbet menar, och en delad routingtabell skickar den gärna till den tunnel som prefixet pekar på. Lösningen är inte fler tunnlar; den är att bestämma var tenantidentiteten kommer in i vägen och vilken isolationsmodell adressplanen kräver. Tre villkor avgör valet: om kundprefixen överlappar, hur långt ett fel kan spridas och vem som driftar connectorn.
Två kunddatabaser, en destinationsadress
En IP-adress är en plats, inte en identitet. Begäran måste bära en tenant som servern har verifierat, och den tenanten måste välja nätverkskontexten innan destinationen slås upp.
När det inte sker är felet tyst. Anslutningen lyckas, frågan körs, och svaret kommer från fel kunds databas eftersom routingtabellen hade en post för 10.20.0.10. DNS gör det värre: ett cachat namn som löstes i tenant A:s kontext kan återanvändas av ett jobb som körs för tenant B. Ingenting i paketet skiljer de två, så ingen återförsökslogik reparerar det.
Bestäm isolationsmodellen först
Skriv ner de tre villkoren innan du jämför produkter. Överlapp avgör om ett adressutrymme alls kan delas; blast radius avgör om ett routingfel är en supportbiljett eller ett intrång; operativt ägarskap avgör om du kan drifta en connectorflotta 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 |
Om prefixen är olika och policyn tillåter en kontrollerad hubb är en Transit Gateway med routingtabeller per tenant genomförbar. Attachment-associationen väljer den routingtabell som används för trafik som kommer in från det attachmentet, och propageringen väljer vilka rutter som visas i en tabell. Ett tenant-attachment som bara är kopplat till sin egen tabell och bara propagerar sina egna prefix når hubben och inget annat. Det är ett routingbeslut, och det förblir bara korrekt så länge ingen lägger till en standardrutt i den delade tabellen.
Om prefixen överlappar kan routing ensamt inte separera dem. Du behöver antingen en egen nätverkskontext per tenant eller en översättningsplan som ger varje kunds utrymme en entydig betydelse.
Vad Transit Gateway-isolering egentligen innebär
Association och propagering är de två rattarna som spelar roll, och de är lätta att förväxla. Association svarar på vilken tabell ett paket från detta attachment slås upp i; propagering svarar på vilka tabeller som lär sig attachmentets rutter. Isolering kommer av att göra båda tenantspecifika, inte av att skapa fler attachments.
En standardinställning alla-till-alla är bekväm och är inte isolering. Separata routingtabeller begränsar anslutningen, men de ger inte en oförändrad destinationsadress två betydelser inom samma routingkontext. Om applikationen löser upp 10.20.0.10 innan den känner till tenanten har routinglagret redan tappat informationen det skulle behöva.
AWS lade till 23 oktober 2026 1:1-NAT på attachment-nivå för Transit Gateway och Cloud WAN, vilket ändrar överlapps svaret för stödda attachments. Transit Gateway NAT-dokumentationen beskriver statiska, tillståndslösa IPv4-mappningar med lika prefix och bevarade värdbitar. Kontrollera stödda attachment-typer och regionala begränsningar innan du designar runt det.
Bind jobbet till en verifierad tenant
Varje jobb bör bära en serververifierad tenantidentitet, och den identiteten bör välja en anslutningspost som administratören äger. Posten namnger den godkända nätverkskontexten, tjänstadressen, referensen till autentiseringsuppgifterna och de operationer som tillåts där. En obetrodd begäran får aldrig tillhandahålla sin egen VPN-identifierare, gateway eller privata mål, eftersom en giltig inloggning inte är tillstånd att undersöka varje ansluten kunds adressutrymme.
I en design med isolerade connectrar går tenant A:s arbete till en A-specifik connector som körs i A:s VPC och bara kan nå A:s godkända resurser. Separata containrar på en värd skapar inte den separationen av sig själva; nätverksnamnrymderna, rutterna och egress-policyn måste implementera den. Connectorn behöver också tenantbegränsade autentiseringsuppgifter och köer, eftersom en privat rutt inte begränsar en delad hemlighet eller ett delat arbetsmoment. Poolade applikationsworkers är okej så länge nätverkskontexten och autentiseringsuppgifterna väljs per tenant, inte per värd.
Hälsokontroller bör namnge tenanten och steget: tunnel upprättad, rutt närvarande och en verklig tjänstebegäran som lyckades är tre olika signaler. Ett aggregerat antal tunnlar som är uppe kommer att dölja den enda kund vars connector är trasig.
Testa vägarna som måste misslyckas
Kör tre tester före lansering. En tillåten A-operation måste lyckas, en tillåten B-operation måste lyckas, och ett A-jobb som medvetet riktas mot B:s connector eller dess översatta alias måste misslyckas stängt. Bryt sedan en tunnel och bekräfta att jobbet misslyckas bara för den tenanten, utan att falla tillbaka till en annan kunds subnet med samma nummer. Återställning bör också testas, eftersom en inaktuell rutt eller cachade autentiseringsuppgifter kan överleva avbrottet.
Arkitekturen kan vara poolade workers med isolerade connectrar, eller helt separata tenantresurser. Invarianten är densamma: verifierad tenantkontext väljer rutten och autentiseringsuppgifterna, och ingen ruttändring ger någonsin applikationen behörighet mellan tenants.