VPN multiinquilino: puerta de enlace compartida, por inquilino o por host
Un túnel no es aislamiento entre inquilinos. Compare una puerta de enlace compartida, puertas por inquilino y conexiones por host en cuanto a asignación de identidades, enrutamiento y retirada.
Decida quién admite a un cliente y qué impide que ese cliente alcance los recursos de otro inquilino. Son dos decisiones, y elegir IPsec, WireGuard o un producto de malla no responde a ninguna. Un túnel que se levanta perfectamente puede dejar igualmente a cada inquilino capaz de alcanzar a todos los demás, y una revisión que trata ambas cosas como la misma aprueba el diseño equivocado. Escriba primero el mapa de cliente a recurso: administradores, acceso de soporte, servicios compartidos y las rutas que deben seguir denegadas.
Empiece por el mapa, no por el producto
Ese mapa es el primer artefacto, y cada opción de abajo es solo una decisión sobre dónde vive la frontera que lo aplica. Manténgalo revisable: una fila por cliente, una fila por servicio compartido y las rutas denegadas escritas.
Un mapa que nadie puede leer es un mapa que nadie aplicará.
Un único punto de admisión y su problema de asignación
Cada ubicación se decide con una sola pregunta operativa, y la tabla es toda la comparación.
| Placement | The question it lives or dies on |
|---|---|
| One shared gateway | How does an admitted identity end up limited to its own resources and its own routing context? |
| A gateway per tenant | Who owns each gateway, its credentials, its policy, its updates and its eventual retirement? |
| A connection per hosted machine | How do enrollment, per-machine policy and replacement work at fleet scale? |
Una puerta de enlace compartida centraliza la admisión y concentra el riesgo en un solo lugar: la asociación entre la identidad de un inquilino y su política. Los grupos o las direcciones de túnel deben resolverse en los permisos de recurso correctos, y una etiqueta distinta por cliente no impide nada por sí sola. Los contextos de enrutamiento separados pueden mantener prefijos solapados cuando la plataforma lo admite y el diseño está completo. Una tabla de enrutamiento compartida simple no puede distinguir dos prefijos de destino idénticos solo porque las personas detrás tengan cuentas distintas.
Esa es la prueba para la mayoría de los diseños. Dos inquilinos que numeran internamente con 10.0.0.0/8 necesitan estado de enrutamiento separado, no una convención de nombres.
Una puerta de enlace por inquilino compra fronteras y sistemas
Una puerta de enlace por cliente hace fáciles de explicar algunas fronteras administrativas, porque la admisión y la política de ese cliente están juntas. También multiplica los sistemas que necesitan credenciales, parches, monitorización y un propietario. Y no impone una única disposición prescrita de direcciones públicas: compartir extremos, la traducción y el desmultiplexado de protocolos dependen de lo que la implementación admita de verdad.
Cuente los sistemas y las personas antes de contar la ganancia de seguridad. Un diseño con cuatro puertas de enlace más de las que el equipo puede parchear no es más aislado en la práctica.
Si el número de inquilinos se mueve cada mes, ese modelo necesita una historia de automatización y no una plantilla.
Las conexiones por host mueven el trabajo
Una conexión en cada máquina alojada no elimina el trabajo operativo, lo traslada al ciclo de vida de la máquina. El alta, la política por máquina, la rotación de claves y el reemplazo pasan a formar parte del aprovisionamiento, y fallan dentro de la misma ventana que la propia máquina. Para un puñado de hosts longevos en redes distintas suele ser correcto, y para una flota que ya perdió la cuenta de qué imagen corre dónde rara vez lo es.
Nombre un rol para la emisión de identidad, las actualizaciones, la retirada de acceso, la monitorización y la recuperación en cada opción. Después pregunte qué ocurre el día en que un cliente se marcha.
La retirada pertenece a la comparación
La mayoría de las comparaciones omite la retirada. Quitar un inquilino debe invalidar sus credenciales, descartar su política, liberar sus direcciones y su estado de enrutamiento y dejar intacto a todos los demás. La guía de arquitectura de confianza cero de NIST es la referencia correcta aquí, porque pone la autenticación y la autorización en el recurso en lugar de confiar en una posición de red, y eso también se aplica dentro del propio segmento de un cliente.
Pese los flujos permitidos y denegados, el tratamiento de direcciones solapadas y el procedimiento de retirada antes de pesar los referentes de protocolo. Después elija un transporte y un método de autenticación que encajen con la frontera elegida. Un nombre de producto más antiguo, o la afirmación de que toda empresa debe estandarizarse en un solo protocolo, no resuelve nada de eso. El mapa que escribió primero lo hace.