Cómo dirigir el tráfico SaaS al VPN correcto del cliente
Las subredes de clientes solapadas rompen el enrutamiento compartido. Elija un modelo de aislamiento, vincule cada trabajo a un inquilino verificado y pruebe las rutas entre inquilinos antes del lanzamiento.
Una plataforma SaaS se conecta con una docena de redes de clientes, y dos de esos clientes usan ambos 10.20.0.10 para su base de datos principal. Un trabajador que recibe esa dirección en un trabajo no tiene forma de saber qué base de datos quiere decir el trabajo, y una tabla de enrutamiento compartida lo enviará de buena gana al túnel al que apunta el prefijo. La solución no son más túneles; es decidir dónde entra la identidad del inquilino en la ruta y qué modelo de aislamiento exige el plan de direcciones. Tres condiciones deciden la elección: si los prefijos de los clientes se solapan, hasta dónde puede propagarse un error y quién opera el conector.
Dos bases de datos de clientes, una dirección de destino
Una dirección IP es una ubicación, no una identidad. La solicitud debe llevar un inquilino que el servidor haya verificado, y ese inquilino debe seleccionar el contexto de red antes de que se resuelva el destino.
Cuando no lo hace, el fallo es silencioso. La conexión se realiza, la consulta se ejecuta y la respuesta proviene de la base de datos del cliente equivocado porque la tabla de enrutamiento tenía una entrada para 10.20.0.10. El DNS lo empeora: un nombre en caché que se resolvió dentro del contexto del inquilino A puede ser reutilizado por un trabajo que se ejecuta para el inquilino B. Nada en el paquete distingue a los dos, así que ninguna cantidad de lógica de reintentos lo repara.
Decida primero el modelo de aislamiento
Escriba las tres condiciones antes de comparar productos. El solapamiento decide si un espacio de direcciones puede compartirse; el radio de impacto decide si un error de enrutamiento es un ticket de soporte o una brecha; la propiedad operativa decide si puede ejecutar una flota de conectores por inquilino.
| 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 |
Si los prefijos son distintos y la política permite un concentrador controlado, un Transit Gateway con tablas de enrutamiento por inquilino es viable. La asociación de la conexión elige la tabla de enrutamiento utilizada para el tráfico que entra desde esa conexión, y la propagación elige qué rutas aparecen en una tabla. Una conexión de inquilino asociada solo con su propia tabla y que propaga solo sus propios prefijos llega al concentrador y a nada más. Esa es una decisión de enrutamiento, y solo sigue siendo correcta mientras nadie añada una ruta predeterminada a la tabla compartida.
Si los prefijos se solapan, el enrutamiento por sí solo no puede separarlos. Necesita un contexto de red distinto por inquilino o un plan de traducción que dé al espacio de cada cliente un significado inequívoco.
Qué significa realmente el aislamiento de Transit Gateway
La asociación y la propagación son los dos controles que importan, y son fáciles de confundir. La asociación responde en qué tabla se busca un paquete de esta conexión; la propagación responde qué tablas aprenden las rutas de esta conexión. El aislamiento proviene de hacer ambos específicos del inquilino, no de crear más conexiones.
Una configuración predeterminada de todos con todos es cómoda y no es aislamiento. Las tablas de enrutamiento separadas restringen la conectividad, pero no dan dos significados a una misma dirección de destino sin cambios dentro del mismo contexto de enrutamiento. Si la aplicación resuelve 10.20.0.10 antes de conocer al inquilino, la capa de enrutamiento ya ha perdido la información que necesitaría.
AWS añadió el 23 de octubre de 2026 NAT 1:1 a nivel de conexión para Transit Gateway y Cloud WAN, lo que cambia la respuesta al solapamiento para las conexiones compatibles. La documentación de NAT de Transit Gateway describe asignaciones IPv4 estáticas, sin estado y de prefijo igual con los bits de host preservados. Compruebe los tipos de conexión compatibles y las restricciones regionales antes de diseñar en torno a ello.
Vincule el trabajo a un inquilino verificado
Cada trabajo debe llevar una identidad de inquilino verificada por el servidor, y esa identidad debe seleccionar un registro de conexión propiedad del administrador. El registro nombra el contexto de red aprobado, la dirección del servicio, la referencia de credenciales y las operaciones permitidas allí. Una solicitud no confiable nunca debe proporcionar su propio identificador de VPN, puerta de enlace o destino privado, porque un inicio de sesión válido no es permiso para sondear el espacio de direcciones de cada cliente conectado.
En un diseño de conectores aislados, el trabajo del inquilino A va a un conector específico de A que se ejecuta en la VPC de A y solo puede alcanzar los recursos aprobados de A. Los contenedores separados en un mismo host no crean esa separación por sí solos; los espacios de nombres de red, las rutas y la política de salida deben implementarla. El conector también necesita credenciales y colas con alcance de inquilino, ya que una ruta privada no limita un secreto compartido ni un elemento de trabajo compartido. Los trabajadores de aplicaciones agrupados están bien siempre que el contexto de red y las credenciales se elijan por inquilino, no por host.
Las comprobaciones de estado deben nombrar al inquilino y la etapa: túnel establecido, ruta presente y una solicitud de servicio real exitosa son tres señales diferentes. Un recuento agregado de túneles activos ocultará al único cliente cuyo conector está roto.
Pruebe las rutas que deben fallar
Ejecute tres pruebas antes del lanzamiento. Una operación A permitida debe tener éxito, una operación B permitida debe tener éxito, y un trabajo A dirigido deliberadamente al conector de B o a su alias traducido debe fallar cerrado. Luego rompa un túnel y confirme que el trabajo falla solo para ese inquilino, sin recurrir a la subred del mismo número de otro cliente. La restauración también debe probarse, porque una ruta obsoleta o una credencial en caché pueden sobrevivir a la interrupción.
La arquitectura puede ser trabajadores agrupados con conectores aislados, o recursos de inquilino totalmente separados. El invariante es el mismo: el contexto de inquilino verificado selecciona la ruta y las credenciales, y ningún cambio de ruta otorga jamás permiso de aplicación entre inquilinos.