Como dirixir o tráfico SaaS ao VPN correcto do cliente

Unha plataforma SaaS conéctase cunha ducia de redes de clientes, e dous deses clientes usan ambos 10.20.0.10 para a súa base de datos principal. Un traballador que recibe ese enderezo nun traballo non ten forma de saber que base de datos quere dicir o traballo, e unha táboa de encamiñamento compartida enviarao de boa gana ao túnel ao que apunta o prefixo. A solución non son máis túneles; é decidir onde entra a identidade do inquilino na ruta e que modelo de illamento esixe o plan de enderezos. Tres condicións deciden a elección: se os prefixos dos clientes se solapan, ata onde pode propagarse un erro e quen opera o conector.

Dúas bases de datos de clientes, un enderezo de destino

Un enderezo IP é unha localización, non unha identidade. A solicitude debe levar un inquilino que o servidor verificase, e ese inquilino debe seleccionar o contexto de rede antes de que se resolva o destino.

Cando non o fai, o fallo é silencioso. A conexión realízase, a consulta execútase e a resposta vén da base de datos do cliente equivocado porque a táboa de encamiñamento tiña unha entrada para 10.20.0.10. O DNS empeórao: un nome na caché que se resolveu dentro do contexto do inquilino A pode ser reutilizado por un traballo que se executa para o inquilino B. Nada no paquete distingue os dous, así que ningunha lóxica de reintentos o arranxa.

Decida primeiro o modelo de illamento

Escriba as tres condicións antes de comparar produtos. O solapamento decide se un espazo de enderezos se pode compartir; o raio de impacto decide se un erro de encamiñamento é un ticket de soporte ou unha brecha; a propiedade operativa decide se pode executar unha frota de conectores por inquilino.

Se os prefixos son distintos e a política permite un concentrador controlado, un Transit Gateway con táboas de encamiñamento por inquilino é viable. A asociación da conexión elixe a táboa de encamiñamento utilizada para o tráfico que entra desde esa conexión, e a propagación elixe que rutas aparecen nunha táboa. Unha conexión de inquilino asociada só coa súa propia táboa e que propaga só os seus propios prefixos chega ao concentrador e a nada máis. Iso é unha decisión de encamiñamento, e só segue sendo correcta mentres ninguén engade unha ruta predeterminada á táboa compartida.

Se os prefixos se solapan, o encamiñamento por si só non pode separalos. Necesita un contexto de rede distinto por inquilino ou un plan de tradución que dea ao espazo de cada cliente un significado inequívoco.

Que significa realmente o illamento de Transit Gateway

A asociación e a propagación son os dous controis que importan, e son fáciles de confundir. A asociación responde en que táboa se busca un paquete desta conexión; a propagación responde que táboas aprenden as rutas desta conexión. O illamento vén de facer ambos específicos do inquilino, non de crear máis conexións.

Unha configuración predeterminada de todos con todos é cómoda e non é illamento. As táboas de encamiñamento separadas restrinxen a conectividade, pero non dan dous significados a un mesmo enderezo de destino sen cambios dentro do mesmo contexto de encamiñamento. Se a aplicación resolve 10.20.0.10 antes de coñecer o inquilino, a capa de encamiñamento xa perdeu a información que necesitaría.

AWS engadiu o 23 de outubro de 2026 NAT 1:1 a nivel de conexión para Transit Gateway e Cloud WAN, o que cambia a resposta ao solapamento para as conexións compatibles. A documentación de NAT de Transit Gateway describe asignacións IPv4 estáticas, sen estado e de prefixo igual cos bits de host preservados. Comprobe os tipos de conexión compatibles e as restricións rexionais antes de deseñar arredor diso.

Vincule o traballo a un inquilino verificado

Cada traballo debe levar unha identidade de inquilino verificada polo servidor, e esa identidade debe seleccionar un rexistro de conexión propiedade do administrador. O rexistro nomea o contexto de rede aprobado, o enderezo do servizo, a referencia das credenciais e as operacións permitidas alí. Unha solicitude non fiable nunca debe proporcionar o seu propio identificador de VPN, pasarela ou destino privado, porque un inicio de sesión válido non é permiso para sondar o espazo de enderezos de cada cliente conectado.

Nun deseño de conectores illados, o traballo do inquilino A vai a un conector específico de A que se executa na VPC de A e só pode alcanzar os recursos aprobados de A. Os contedores separados nun mesmo host non crean esa separación por si sós; os espazos de nomes de rede, as rutas e a política de saída deben implementala. O conector tamén necesita credenciais e colas con alcance de inquilino, xa que unha ruta privada non limita un segredo compartido nin un elemento de traballo compartido. Os traballadores de aplicacións agrupados están ben sempre que o contexto de rede e as credenciais se elixan por inquilino, non por host.

As comprobacións de saúde deben nomear o inquilino e a etapa: túnel establecido, ruta presente e unha solicitude de servizo real exitosa son tres sinais diferentes. Un reconto agregado de túneles activos ocultará o único cliente cuxo conector está roto.

Probe os camiños que deben fallar

Execute tres probas antes do lanzamento. Unha operación A permitida debe ter éxito, unha operación B permitida debe ter éxito, e un traballo A dirixido deliberadamente ao conector de B ou ao seu alias traducido debe fallar pechado. Logo rompa un túnel e confirme que o traballo falla só para ese inquilino, sen caer na subrede do mesmo número doutro cliente. A restauración tamén se debe probar, porque unha ruta obsoleta ou unha credencial na caché poden sobrevivir á interrupción.

A arquitectura pode ser traballadores agrupados con conectores illados, ou recursos de inquilino totalmente separados. O invariante é o mesmo: o contexto de inquilino verificado selecciona a ruta e as credenciais, e ningún cambio de ruta outorga xamais permiso de aplicación entre inquilinos.