Gestionar una IP separada y un listener separado para cada dominio no escala.
En las arquitecturas ADC y de proxy inverso tradicionales, cada nuevo dominio suele significar un nuevo listener, un nuevo servicio virtual, una nueva dirección IP o un conjunto complejo de reglas de enrutamiento. A pequeña escala esto es manejable, pero una vez que el número de dominios llega a docenas, los tenants alcanzan cientos o se requiere separación multi-entorno, la superficie operacional se desmorona rápidamente.
En el lado TLS el problema es más agudo. La cabecera Host HTTP no es visible hasta que se termina TLS, por lo que enrutar el tráfico TLS al servicio correcto requiere una decisión a nivel SNI — antes de que se complete la negociación. Sin una separación SNI adecuada, los dominios que comparten la misma IP se mezclan, se sirve el certificado equivocado o el tráfico llega al backend incorrecto.
La gestión de dominios wildcard añade una carga adicional. Patrones como `*.tenant.app` son comunes en escenarios SaaS y MSP, pero definir manualmente cada subdominio no es sostenible. El wildcard debe convertirse en la regex correcta, correctamente escapada y restringida para que no coincida con dominios no deseados.
La semántica HTTP/2 y TLS moderna hace que el manejo de dominios no coincidentes sea aún más sensible. Cuando SNI y la cabecera Host no coinciden, el cliente espera un comportamiento bien definido; si la plataforma no puede producirlo, las conexiones aterrizan en el pool incorrecto o los controles de seguridad se eluden.
TR7 ADC trata los hosts virtuales como una relación dominio + coincidencia + pool. Separa los dominios en la misma IP y puerto mediante SNI o cabecera Host, gestiona los dominios wildcard automáticamente y vincula cada dominio a su propia política de servicio.
Nuestro enfoque
TR7 elimina la duplicación manual de listeners de la gestión de hosts virtuales y gestiona el enrutamiento basado en dominios mediante un modelo de objetos, generación automática de coincidencias y un proceso de recarga sin tiempo de inactividad.
Dos modos de coincidencia: SNI y cabecera Host
Para el tráfico TLS la decisión se toma sobre el valor SNI; para el tráfico HTTP se utiliza la cabecera Host. Tanto los escenarios de separación temprana TLS como los escenarios clásicos de proxy inverso HTTP se gestionan bajo el mismo modelo de host virtual.
Los dominios wildcard se convierten automáticamente en reglas de coincidencia
Las entradas wildcard como `*.example.com` se convierten automáticamente en patrones de coincidencia seguros. Los operadores no escriben regex a mano. Una única definición wildcard enruta subdominios ilimitados al pool correcto.
Cada dominio se vincula a su propio pool y cadena de políticas
Cada dominio que comparte una VIP puede apuntar a un pool diferente. Esto significa que un dominio puede llevar un perfil WAAP, otro mTLS, otro un perfil de caché o log personalizado. La separación de dominios no es solo enrutamiento — es separación de políticas.
Configuración determinista y recarga idempotente
TR7 genera la configuración de hosts virtuales en un orden ordenado y determinista. Dado que la misma entrada siempre produce la misma salida, se evitan recargas innecesarias. Una recarga suave se aplica solo cuando se detecta un cambio real, preservando las conexiones activas.
Capacidades
Los Hosts Virtuales proporcionan separación basada en dominios, gestión de wildcards, vinculación de certificados, aislamiento de tenants y actualizaciones sin tiempo de inactividad en la misma IP y puerto.
Enrutamiento de host virtual basado en SNI
En el tráfico TLS el valor SNI presentado por el cliente se lee y el dominio coincidente se dirige al pool correcto. Esto permite la separación de dominios en la fase más temprana de la conexión TLS. Es el mecanismo central para ejecutar múltiples servicios TLS en un único puerto 443.
Enrutamiento HTTP basado en cabecera Host
En modo HTTP TR7 utiliza el valor de la cabecera `Host` para la coincidencia de hosts virtuales. Se logra el comportamiento clásico de vhost para HTTP plano y para el tráfico HTTP tras la terminación TLS. Los diferentes dominios en la misma IP y puerto se reenvían a pools de servicio distintos.
Soporte de dominios wildcard
Los nombres wildcard como `*.example.com` se convierten automáticamente en reglas de coincidencia. Los operadores no escriben una regla separada para cada subdominio. Esto es especialmente potente para dominios de tenants SaaS, subdominios de clientes y separación multi-entorno.
Vinculación de pool por dominio
Cada dominio virtual se vincula a un ID de pool. `shop.example.com`, `api.example.com` y `admin.example.com` en la misma VIP pueden apuntar a backends diferentes. Cada pool gestiona su propia lista de backends, health checks, WAAP y reglas de tráfico de forma independiente.
Perfil WAAP, caché y log por dominio
Un host virtual no es solo una decisión de enrutamiento — las políticas de seguridad y operacionales también divergen a través del pool al que está vinculado cada dominio. Un dominio puede aplicar un perfil WAAP estricto mientras otro se acelera con un perfil de caché. El formato de log y los informes pueden configurarse por dominio y pool.
Alineación de certificados y SNI
Cuando se utilizan múltiples certificados en la misma IP y puerto, TR7 ejecuta la cadena correcta de certificado y pool basándose en el valor SNI. Los certificados wildcard y los vhosts wildcard pueden usarse juntos, simplificando las operaciones TLS multi-dominio.
La cadena de metadatos proxy se preserva
La capa de host virtual admite el reenvío de información de contexto de cliente y geográfico a las capas posteriores durante el enrutamiento de tráfico. Los pools de backend, el registro, las decisiones geográficas y las cadenas de políticas pueden por tanto continuar usando el contexto requerido después de la separación de dominios.
Arquitectura de socket tunnel de pool
La capa de host virtual reenvía el tráfico al pool relevante a través de una conexión interna aislada. Esta arquitectura realiza la separación de dominios en un punto central mientras mantiene el espacio de trabajo de cada pool aislado. El tráfico de un portal, AAM u otro pool puede gestionarse con el mismo modelo.
Gestión de vhost multi-tenant consciente de zonas
En despliegues multi-tenant cada zona gestiona su propia lista de hosts virtuales. La lista de dominios de un tenant no se mezcla con los dominios de otro tenant. Los conflictos de dominio, los límites de permisos y la visibilidad se mantienen dentro de los límites del tenant.
Modelo de operación adaptado a altos recuentos de conexiones
Los grupos de hosts virtuales se mantienen en espacios de trabajo separados para altos recuentos de conexiones. El tráfico multi-dominio se gestiona de forma centralizada sin restringir la capacidad de conexiones. Los cambios operacionales en un grupo de dominios no afectan innecesariamente a otros grupos.
Actualizaciones sin tiempo de inactividad con recarga suave
Cuando cambia un dominio, pool o certificado, TR7 detecta la diferencia de configuración. Solo el componente afectado se actualiza mediante recarga suave. Las conexiones existentes se drenan mientras el nuevo tráfico se acepta bajo la configuración actualizada.
El comportamiento para dominios no definidos es controlable
Los valores de Host o SNI no definidos pueden dirigirse a un backend predeterminado, una respuesta de error o una política de seguridad. Esto proporciona un comportamiento controlado en escenarios de secuestro de subdominios y acceso a dominios inesperados.
Profundidad operacional
La capacidad de Hosts Virtuales aborda no solo la coincidencia de dominios sino también la estrategia de recarga, la separación de tenants, la normalización de wildcards y la operación con altos recuentos de conexiones.
Lógica de grupos
Los hosts virtuales que comparten la misma IP, puerto y tipo de operación se tratan como un grupo. Las asignaciones de dominios dentro del grupo se generan en un orden ordenado y determinista. Esta estructura evita diferencias de configuración espurias.
Generación de coincidencias
Los valores de dominio exactos se gestionan con coincidencia directa de cadena; los dominios wildcard se gestionan con coincidencia de patrón automática. Dado que los operadores no escriben regex manualmente, el riesgo de errores se reduce. Los caracteres de dominio se escapan de forma segura.
Separación SNI / Host
En modo TLS la decisión se toma sobre el valor SNI; en modo HTTP sobre la cabecera Host. Esta separación es automática. Los operadores no necesitan escribir una lógica de enrutamiento diferente para cada escenario.
Análisis de diferencias de configuración
TR7 compara la configuración actual con la configuración que debe generarse. Se toma una decisión de recarga o reinicio solo si existe una diferencia real. Si nada ha cambiado, no se toma ninguna acción.
Comportamiento de recarga suave
Una recarga suave se aplica solo cuando la configuración del proxy en ejecución ha cambiado. Esto evita la interrupción innecesaria de las conexiones activas. Si se requiere un cambio más profundo en el espacio de trabajo, se realiza un reinicio controlado.
Visibilidad de tenants
Cada zona ve su propia configuración de dominios y vhosts. La gestión de dominios está separada en despliegues multi-cliente o multi-departamento. Este enfoque mejora tanto la seguridad operacional como la simplicidad de gestión.
Dependencia del pool
El enrutamiento de hosts virtuales solo es significativo cuando el pool relevante está activo y en buen estado. Los health checks del pool, el estado del backend, los certificados y el perfil WAAP determinan la cadena de decisión final para el tráfico del dominio.
Comportamiento HTTP/2 y de solicitudes mal dirigidas
En clientes modernos, una discrepancia entre SNI y la cabecera Host puede hacer que el tráfico llegue al backend incorrecto. TR7 hace que tales situaciones sean controlables a través de la cadena de host virtual y perfil de seguridad.
Cuándo utilizarlo
Gestión de subdominios SaaS multi-tenant
`tenant1.app.com`, `tenant2.app.com` y `tenant3.app.com` comparten la misma VIP. Una regla de dominio wildcard captura todos los subdominios de tenants bajo una única entrada; cada tenant se enruta a su propio pool y perfil WAAP.
Separación de e-commerce y panel de administración en la misma IP
`shop.example.com` va al pool de tienda pública; `admin.example.com` va a un pool de gestión con mTLS y una política de acceso más estricta. Se utiliza un único puerto 443 y las políticas de seguridad se separan a nivel de dominio.
División de versiones de API con dominios
`api.example.com` se enruta al pool de nueva API mientras `api-v2.example.com` va al pool legado. Durante la transición ambos servicios comparten la misma IP; la arquitectura de DNS y firewall permanece sin cambios.
Funcionamiento con una cadena de políticas geográficas
La capa de host virtual separa el dominio; la capa de pool posterior aplica diferentes reglas de tráfico o perfiles de seguridad basándose en información geográfica. Una cadena de decisiones por dominio y ubicación opera de extremo a extremo.
Reducción del riesgo de secuestro de subdominios
Las solicitudes de subdominios no definidos o inesperados se colocan bajo un comportamiento de seguridad predeterminado. Incluso cuando se utiliza un certificado wildcard, los backends no controlados no pueden ser alcanzados por subdominios inesperados.
Portal público y API privada en una única VIP
`portal.example.com` está abierto a los usuarios de internet mientras `partner-api.example.com` solo es accesible con mTLS y una allowlist de IP. Ambos servicios comparten la misma IP y puerto, cada uno bajo su propia capa de seguridad.
Preguntas frecuentes
¿Cuál es la diferencia entre el enrutamiento basado en SNI y el basado en cabecera Host?
¿Cómo se gestionan los dominios wildcard?
¿Cuántos dominios pueden ejecutarse en la misma VIP?
¿Se interrumpen las conexiones cuando se cambia un dominio?
¿Puede usarse un perfil WAAP o de caché separado por dominio?
¿Qué ocurre cuando llega una solicitud para un dominio no definido?
Gestione todos sus dominios sobre una única VIP
Separación por SNI y cabecera Host, soporte de dominios wildcard, WAAP por dominio y recarga sin tiempo de inactividad. Permítanos guiarle por una configuración en vivo en su propia infraestructura.