Com encaminar el trànsit SaaS al VPN correcte del client

Una plataforma SaaS es connecta a una dotzena de xarxes de clients, i dos d’aquests clients fan servir 10.20.0.10 per a la seva base de dades principal. Un treballador que rep aquesta adreça en una feina no té manera de saber quina base de dades vol dir la feina, i una taula d’encaminament compartida l’enviarà de bon grat al túnel que assenyali el prefix. La solució no és més túnels; és decidir on entra la identitat de l’inquilí al camí i quin model d’aïllament requereix el pla d’adreces. Tres condicions decideixen l’elecció: si els prefixos dels clients se solapen, fins on pot arribar un error i qui opera el connector.

Dues bases de dades de clients, una adreça de destinació

Una adreça IP és una ubicació, no una identitat. La petició ha de portar un inquilí que el servidor hagi verificat, i aquest inquilí ha de seleccionar el context de xarxa abans que es resolgui la destinació.

Quan no ho fa, la fallada és silenciosa. La connexió s’estableix, la consulta s’executa i la resposta ve de la base de dades del client equivocat perquè la taula d’encaminament tenia una entrada per a 10.20.0.10. El DNS ho empitjora: un nom en memòria cau que es va resoldre dins del context de l’inquilí A pot ser reutilitzat per una feina que corre per a l’inquilí B. Res al paquet distingeix els dos, així que cap quantitat de lògica de reintents ho arregla.

Decidiu primer el model d’aïllament

Escriviu les tres condicions abans de comparar productes. El solapament decideix si un espai d’adreces es pot compartir; el radi d’impacte decideix si un error d’encaminament és un tiquet de suport o una bretxa; la propietat operativa decideix si podeu executar una flota de connectors per inquilí.

Si els prefixos són diferents i la política permet un concentrador controlat, una Transit Gateway amb taules d’encaminament per inquilí és viable. L’associació d’adjunció tria la taula d’encaminament utilitzada pel trànsit que entra des d’aquesta adjunció, i la propagació tria quines rutes apareixen en una taula. Una adjunció d’inquilí associada només amb la seva pròpia taula i que propaga només els seus prefixos arriba al concentrador i a res més. Això és una decisió d’encaminament, i només es manté correcta mentre ningú afegeixi una ruta per defecte a la taula compartida.

Si els prefixos se solapen, l’encaminament sol no els pot separar. Necessiteu o bé un context de xarxa diferent per inquilí o bé un pla de traducció que doni a l’espai de cada client un significat inequívoc.

Què significa realment l’aïllament de Transit Gateway

L’associació i la propagació són els dos controls que importen, i és fàcil confondre’ls. L’associació respon en quina taula es consulta un paquet d’aquesta adjunció; la propagació respon quines taules aprenen les rutes d’aquesta adjunció. L’aïllament ve de fer que tots dos siguin específics de l’inquilí, no de crear més adjuncions.

Una configuració per defecte de tothom amb tothom és convenient i no és aïllament. Les taules d’encaminament separades limiten la connectivitat, però no donen dues interpretacions a una mateixa adreça de destinació dins del mateix context d’encaminament. Si l’aplicació resol 10.20.0.10 abans de conèixer l’inquilí, la capa d’encaminament ja ha perdut la informació que necessitaria.

AWS va afegir el 23 d’octubre de 2026 NAT 1:1 a nivell d’adjunció per a Transit Gateway i Cloud WAN, cosa que canvia la resposta sobre el solapament per a les adjuncions admeses. La documentació de NAT de Transit Gateway descriu mapatges IPv4 estàtics, sense estat i d’igual prefix amb els bits d’amfitrió preservats. Comproveu els tipus d’adjunció admesos i les restriccions regionals abans de dissenyar-hi al voltant.

Lligueu la feina a un inquilí verificat

Cada feina ha de portar una identitat d’inquilí verificada pel servidor, i aquesta identitat ha de seleccionar un registre de connexió propietat de l’administrador. El registre nomena el context de xarxa aprovat, l’adreça del servei, la referència de credencials i les operacions permeses allà. Una petició no fiable no ha de proporcionar mai el seu propi identificador de VPN, passarel·la o objectiu privat, perquè un inici de sessió vàlid no és permís per sondar l’espai d’adreces de cada client connectat.

En un disseny de connectors aïllats, la feina de l’inquilí A va a un connector específic d’A que s’executa a la VPC d’A i només pot arribar als recursos aprovats d’A. Els contenidors separats en un mateix amfitrió no creen aquesta separació per si sols; els espais de noms de xarxa, les rutes i la política de sortida l’han d’implementar. El connector també necessita credencials i cues amb abast d’inquilí, perquè una ruta privada no limita un secret compartit ni un element de treball compartit. Els treballadors d’aplicació agrupats estan bé sempre que el context de xarxa i les credencials es triïn per inquilí, no per amfitrió.

Les comprovacions de salut han de nomenar l’inquilí i l’etapa: túnel establert, ruta present i una petició de servei real que ha tingut èxit són tres senyals diferents. Un recompte agregat de túnels actius amagarà l’únic client el connector del qual està trencat.

Proveu els camins que han de fallar

Feu tres proves abans del llançament. Una operació A permesa ha de tenir èxit, una operació B permesa ha de tenir èxit, i una feina A dirigida deliberadament al connector de B o al seu àlies traduït ha de fallar tancada. Després trenqueu un túnel i confirmeu que la feina falla només per a aquest inquilí, sense caure en la subxarxa amb el mateix número d’un altre client. La restauració també s’ha de provar, perquè una ruta obsoleta o una credencial en memòria cau poden sobreviure a la interrupció.

L’arquitectura pot ser de treballadors agrupats amb connectors aïllats, o de recursos d’inquilí completament separats. L’invariant és el mateix: el context d’inquilí verificat selecciona la ruta i les credencials, i cap canvi de ruta no atorga mai permís d’aplicació entre inquilins.