SaaS-verkeer naar de juiste klant-VPN routeren

Een SaaS-platform verbindt naar een dozijn klantnetwerken, en twee van die klanten gebruiken allebei 10.20.0.10 voor hun primaire database. Een worker die dat adres in een taak krijgt, kan niet zien welke database de taak bedoelt, en een gedeelde routingtabel stuurt hem graag naar de tunnel waar het prefix naar wijst. De oplossing is niet meer tunnels; het is beslissen waar tenantidentiteit het pad binnenkomt en welk isolatiemodel het adresplan vereist. Drie voorwaarden bepalen de keuze: of klantprefixen overlappen, hoe ver een fout zich kan verspreiden en wie de connector beheert.

Twee klantdatabases, één bestemmingsadres

Een IP-adres is een locatie, geen identiteit. Het verzoek moet een tenant dragen die de server heeft geverifieerd, en die tenant moet de netwerkcontext kiezen voordat de bestemming wordt opgelost.

Als dat niet gebeurt, is de fout stil. De verbinding slaagt, de query loopt, en het antwoord komt uit de database van de verkeerde klant omdat de routingtabel één vermelding voor 10.20.0.10 had. DNS maakt het erger: een gecachte naam die binnen de context van tenant A is opgelost, kan opnieuw worden gebruikt door een taak die voor tenant B draait. Niets in het pakket onderscheidt de twee, dus geen enkele herhaalpogingslogica herstelt het.

Bepaal eerst het isolatiemodel

Schrijf de drie voorwaarden op voordat u producten vergelijkt. Overlap bepaalt of één adresruimte überhaupt kan worden gedeeld; de blast-radius bepaalt of een routingfout een supportticket of een inbreuk is; operationeel eigenaarschap bepaalt of u een connectorvloot per tenant kunt draaien.

Als de prefixen verschillen en het beleid een gecontroleerde hub toestaat, is één Transit Gateway met routingtabellen per tenant haalbaar. Attachment-associatie kiest de routingtabel die wordt gebruikt voor verkeer dat binnenkomt vanaf dat attachment, en propagatie kiest welke routes in een tabel verschijnen. Een tenant-attachment dat alleen aan zijn eigen tabel is gekoppeld en alleen zijn eigen prefixen propageert, bereikt de hub en niets anders. Dat is een routingbeslissing, en die blijft alleen correct zolang niemand een standaardroute aan de gedeelde tabel toevoegt.

Als prefixen overlappen, kan routing alleen ze niet scheiden. U hebt een aparte netwerkcontext per tenant nodig of een vertaalplan dat de ruimte van elke klant een ondubbelzinnige betekenis geeft.

Wat Transit Gateway-isolatie werkelijk betekent

Associatie en propagatie zijn de twee knoppen die ertoe doen, en ze zijn makkelijk te verwarren. Associatie beantwoordt in welke tabel een pakket van dit attachment wordt opgezocht; propagatie beantwoordt welke tabellen de routes van dit attachment leren. Isolatie komt van het tenantspecifiek maken van beide, niet van het aanmaken van meer attachments.

Een standaard alles-naar-alles-opstelling is handig en is geen isolatie. Aparte routingtabellen beperken de connectiviteit, maar ze geven één onveranderd bestemmingsadres niet twee betekenissen binnen dezelfde routingcontext. Als de applicatie 10.20.0.10 oplost voordat ze de tenant kent, is de routinglaag de informatie die ze nodig had al kwijt.

AWS voegde op 23 oktober 2026 1:1-NAT op attachmentniveau toe voor Transit Gateway en Cloud WAN, wat het overlapantwoord voor ondersteunde attachments verandert. De Transit Gateway NAT-documentatie beschrijft statische, stateloze IPv4-mappings met gelijk prefix en behouden hostbits. Controleer ondersteunde attachmenttypen en regionale beperkingen voordat u hierop ontwerpt.

Koppel de taak aan een geverifieerde tenant

Elke taak moet een door de server geverifieerde tenantidentiteit dragen, en die identiteit moet een door de beheerder beheerd verbindingsrecord kiezen. Het record noemt de goedgekeurde netwerkcontext, het serviceadres, de referentie naar de inloggegevens en de daar toegestane bewerkingen. Een niet-vertrouwd verzoek mag nooit zijn eigen VPN-identificatie, gateway of privédoel leveren, want een geldige login is geen toestemming om de adresruimte van elke verbonden klant te onderzoeken.

In een ontwerp met geïsoleerde connectors gaat het werk van tenant A naar een A-specifieke connector die in de VPC van A draait en alleen de goedgekeurde resources van A kan bereiken. Aparte containers op één host creëren die scheiding niet vanzelf; de netwerk-namespaces, routes en egress-beleid moeten die implementeren. De connector heeft ook tenantgebonden inloggegevens en wachtrijen nodig, want een privéroute begrenst geen gedeeld geheim of gedeeld werkitem. Gepoolde applicatieworkers zijn prima zolang de netwerkcontext en inloggegevens per tenant worden gekozen, niet per host.

Healthchecks moeten de tenant en de fase noemen: tunnel opgezet, route aanwezig en een echte serviceaanvraag geslaagd zijn drie verschillende signalen. Een geaggregeerd aantal tunnels dat up is, verbergt de ene klant wiens connector stuk is.

Test de paden die moeten falen

Voer drie tests uit vóór de lancering. Een toegestane A-bewerking moet slagen, een toegestane B-bewerking moet slagen, en een A-taak die opzettelijk op de connector van B of zijn vertaalde alias is gericht, moet fail-closed falen. Verbreek dan één tunnel en bevestig dat de taak alleen voor die tenant faalt, zonder terug te vallen op het gelijkgenummerde subnet van een andere klant. Herstel moet ook worden getest, want een verouderde route of gecachte inloggegevens kunnen de storing overleven.

De architectuur kan gepoolde workers met geïsoleerde connectors zijn, of volledig gescheiden tenantresources. De invariant is dezelfde: geverifieerde tenantcontext kiest de route en de inloggegevens, en geen enkele routewijziging verleent ooit applicatietoestemming tussen tenants.