Dans les architectures ADC et reverse-proxy traditionnelles, chaque nouveau domaine signifie généralement un nouveau listener, un nouveau service virtuel, une nouvelle adresse IP ou un ensemble complexe de règles de routage. À petite échelle c'est gérable, mais une fois que le nombre de domaines atteint des dizaines, que les tenants atteignent des centaines ou qu'une séparation multi-environnement est requise, la surface opérationnelle s'effondre rapidement.
Côté TLS le problème est plus aigu. Le Host header HTTP est invisible jusqu'à ce que TLS soit terminé, donc router le trafic TLS vers le bon service nécessite une décision au niveau SNI — avant la fin de la poignée de main. Sans une séparation SNI correcte, les domaines partageant la même IP se croisent, le mauvais certificat est présenté ou le trafic arrive sur le mauvais backend.
La gestion des domaines wildcard ajoute un fardeau supplémentaire. Les motifs comme `*.tenant.app` sont courants dans les scénarios SaaS et MSP, mais définir manuellement chaque sous-domaine n'est pas viable. Le wildcard doit être converti en regex correct, correctement échappé et contraint pour ne pas correspondre à des domaines non souhaités.
HTTP/2 et la sémantique TLS moderne rendent la gestion des domaines mal appariés encore plus sensible. Lorsque SNI et le Host header divergent, le client attend un comportement bien défini ; si la plateforme ne peut pas le produire, les connexions arrivent sur le mauvais pool ou les contrôles de sécurité sont contournés.
TR7 ADC traite les hôtes virtuels comme une relation domaine + matcher + pool. Il sépare les domaines sur la même IP et le même port via SNI ou Host header, gère automatiquement les domaines wildcard et lie chaque domaine à sa propre politique de service.
TR7 supprime la duplication manuelle des listeners de la gestion des hôtes virtuels et gère le routage par domaine via un modèle objet, la génération automatique de matchers et un processus de rechargement sans interruption.
Pour le trafic TLS la décision est prise sur la valeur SNI ; pour le trafic HTTP le Host header est utilisé. Les scénarios de séparation précoce TLS et les scénarios classiques de reverse-proxy HTTP sont tous deux gérés sous le même modèle d'hôte virtuel.
Les entrées wildcard telles que `*.example.com` sont automatiquement converties en motifs de correspondance sûrs. Les opérateurs n'écrivent pas de regex à la main. Une seule définition wildcard route des sous-domaines illimités vers le bon pool.
Chaque domaine partageant une VIP peut cibler un pool différent. Cela signifie qu'un domaine peut porter un profil WAAP, un autre mTLS, un autre un cache ou un profil de log personnalisé. La séparation des domaines n'est pas seulement du routage — c'est une séparation de politique.
TR7 génère la configuration des hôtes virtuels dans un ordre trié et déterministe. Comme le même input produit toujours le même output, les rechargements inutiles sont évités. Un rechargement doux n'est appliqué que lorsqu'un vrai changement est détecté, préservant les connexions en direct.
Les Hôtes Virtuels fournissent la séparation par domaine, la gestion des wildcards, la liaison de certificats, l'isolation des tenants et les mises à jour sans interruption sur la même IP et le même port.
Dans le trafic TLS la valeur SNI présentée par le client est lue et le domaine correspondant est dirigé vers le bon pool. Cela permet la séparation des domaines au tout début de la connexion TLS. C'est le mécanisme principal pour exécuter plusieurs services TLS sur un seul port 443.
En mode HTTP TR7 utilise la valeur du header `Host` pour la correspondance des hôtes virtuels. Le comportement vhost classique est obtenu pour le HTTP simple et pour le trafic HTTP après terminaison TLS. Les différents domaines sur la même IP et le même port sont acheminés vers des pools de services distincts.
Les noms wildcard tels que `*.example.com` sont automatiquement convertis en règles de correspondance. Les opérateurs n'écrivent pas de règle séparée pour chaque sous-domaine. C'est particulièrement puissant pour les domaines tenant SaaS, les sous-domaines clients et la séparation multi-environnement.
Chaque domaine virtuel est lié à un ID de pool. `shop.example.com`, `api.example.com` et `admin.example.com` sur la même VIP peuvent cibler des backends différents. Chaque pool gère sa propre liste de backends, ses contrôles de santé, son WAAP et ses règles de trafic indépendamment.
Un hôte virtuel n'est pas seulement une décision de routage — les politiques de sécurité et opérationnelles divergent également via le pool auquel chaque domaine est lié. Un domaine peut appliquer un profil WAAP strict tandis qu'un autre est accéléré avec un profil de cache. Le format de log et le reporting peuvent être configurés par domaine et par pool.
Lorsque plusieurs certificats sont utilisés sur la même IP et le même port, TR7 exécute la bonne chaîne certificat-et-pool basée sur la valeur SNI. Les certificats wildcard et les vhosts wildcard peuvent être utilisés ensemble, simplifiant les opérations TLS multi-domaine.
La couche des hôtes virtuels prend en charge la transmission des informations de contexte client et géographique aux couches en aval lors du routage du trafic. Les pools backend, la journalisation, les décisions géo-basées et les chaînes de politiques peuvent donc continuer à utiliser le contexte requis après la séparation des domaines.
La couche des hôtes virtuels transfère le trafic vers le pool concerné via une connexion interne isolée. Cette architecture effectue la séparation des domaines en un point central tout en gardant l'espace de travail de chaque pool isolé. Le trafic d'un portail, d'un AAM ou d'un autre pool peut être géré avec le même modèle.
Dans les déploiements multi-tenant, chaque zone gère sa propre liste d'hôtes virtuels. La liste de domaines d'un tenant ne se mélange pas avec les domaines d'un autre tenant. Les conflits de domaines, les limites de permissions et la visibilité sont maintenus dans les limites des tenants.
Les groupes d'hôtes virtuels sont maintenus dans des espaces de travail séparés pour les nombres élevés de connexions. Le trafic multi-domaine est géré centralement sans contraindre la capacité de connexion. Les changements opérationnels dans un groupe de domaines n'affectent pas inutilement les autres groupes.
Lorsqu'un domaine, un pool ou un certificat change, TR7 détecte la différence de configuration. Seul le composant affecté est rafraîchi via un rechargement doux. Les connexions existantes sont drainées tandis que le nouveau trafic est accepté sous la configuration mise à jour.
Les valeurs Host ou SNI non définies peuvent être dirigées vers un backend par défaut, une réponse d'erreur ou une politique de sécurité. Cela fournit un comportement contrôlé dans les scénarios de détournement de sous-domaines et d'accès à des domaines inattendus.
La capacité Hôtes Virtuels traite non seulement la correspondance de domaines mais aussi la stratégie de rechargement, la séparation des tenants, la normalisation des wildcards et les opérations à connexions élevées ensemble.
Les hôtes virtuels partageant la même IP, le même port et le même type de fonctionnement sont traités comme un groupe. Les correspondances de domaines à l'intérieur du groupe sont générées dans un ordre trié et déterministe. Cette structure empêche les différences de configuration parasites.
Les valeurs de domaine exactes sont gérées avec une correspondance directe de chaîne ; les domaines wildcard sont gérés avec une correspondance automatique de motif. Comme les opérateurs n'écrivent pas de regex manuellement, le risque d'erreurs est réduit. Les caractères de domaine sont correctement échappés.
En mode TLS la décision est prise sur la valeur SNI ; en mode HTTP sur le Host header. Cette séparation est automatique. Les opérateurs n'ont pas besoin d'écrire une logique de routage différente pour chaque scénario.
TR7 compare la configuration actuelle avec la configuration qui devrait être générée. Une décision de rechargement ou de redémarrage n'est prise que si une vraie différence existe. Si rien n'a changé, aucune action n'est prise.
Un rechargement doux n'est appliqué que lorsque la configuration du proxy en cours d'exécution a changé. Cela empêche l'interruption inutile des connexions actives. Si un changement d'espace de travail plus profond est requis, un redémarrage contrôlé est effectué.
Chaque zone voit sa propre configuration de domaines et vhosts. La gestion des domaines est séparée dans les déploiements multi-clients ou multi-départements. Cette approche améliore à la fois la sécurité opérationnelle et la simplicité de gestion.
Le routage des hôtes virtuels n'a de sens que lorsque le pool concerné est actif et en bonne santé. Les contrôles de santé du pool, l'état du backend, les certificats et le profil WAAP déterminent la chaîne de décision finale pour le trafic du domaine.
Dans les clients modernes, une incompatibilité entre SNI et le Host header peut amener le trafic à atteindre le mauvais backend. TR7 rend ces situations contrôlables via la chaîne d'hôte virtuel et de profil de sécurité.
`tenant1.app.com`, `tenant2.app.com` et `tenant3.app.com` partagent tous la même VIP. Une règle de domaine wildcard capture tous les sous-domaines tenant sous une seule entrée ; chaque tenant est routé vers son propre pool et profil WAAP.
`shop.example.com` va vers le pool de la boutique publique ; `admin.example.com` va vers un pool de gestion avec mTLS et une politique d'accès plus stricte. Un seul port 443 est utilisé et les politiques de sécurité sont séparées au niveau du domaine.
`api.example.com` est routé vers le nouveau pool API tandis que `api-v2.example.com` va vers le pool legacy. Pendant la transition, les deux services partagent la même IP ; l'architecture DNS et pare-feu reste inchangée.
La couche des hôtes virtuels sépare le domaine ; la couche de pool en aval applique différentes règles de trafic ou profils de sécurité basés sur les informations géographiques. Une chaîne de décision basée sur le domaine et la localisation fonctionne de bout en bout.
Les requêtes de sous-domaines non définis ou inattendus sont placées sous un comportement de sécurité par défaut. Même lorsqu'un certificat wildcard est utilisé, les backends non contrôlés ne peuvent pas être atteints par des sous-domaines inattendus.
`portal.example.com` est ouvert aux utilisateurs internet tandis que `partner-api.example.com` n'est accessible qu'avec mTLS et une allowlist IP. Les deux services partagent la même IP et le même port, chacun sous sa propre couche de sécurité.
Séparation SNI et Host header, prise en charge des domaines wildcard, WAAP par domaine et rechargement sans interruption. Laissez-nous vous guider à travers une configuration en direct sur votre propre infrastructure.