L'un des problèmes les plus difficiles dans les réseaux d'entreprise est de gérer différents domaines réseau sur le même appareil de manière sécurisée et sans conflits d'adresses. Dans les environnements MSP, gouvernementaux, financiers, de santé et multi-tenant, chaque tenant peut apporter son propre plan IP. La réutilisation du même bloc CIDR chez différents clients est courante.
La séparation de routes classique n'isole généralement que la table de routage. Une véritable isolation, cependant, nécessite plus que des routes — les interfaces, l'ARP, le pare-feu, les sockets et le comportement des connexions doivent tous être séparés. Sans cela, le `10.0.0.5` du Tenant A et le `10.0.0.5` du Tenant B deviennent opérationnellement et sécuritairement risqués sur le même appareil.
Un second problème se pose lorsque les services doivent rester dans différents domaines réseau. Une VIP doit écouter côté DMZ, le backend doit rester sur le réseau interne, le trafic de gestion doit être confiné à sa propre table de routage, ou l'ancien et le nouveau réseau doivent coexister pendant la migration. Fusionner de force ces domaines brise la segmentation de sécurité et l'ordre opérationnel.
La bonne approche consiste à isoler chaque domaine réseau dans sa propre table de routage et à fournir un croisement contrôlé au niveau du vService. Un vService doit pouvoir écouter sur plusieurs tables de routage et transférer le trafic vers des backends dans différentes tables de routage.
Le Routage Cross-NS de TR7 répond à ce besoin : il crée des domaines réseau isolés sur un seul appareil, sépare les plans IP chevauchants et transforme le vService en pont de trafic contrôlé entre les tables de routage.
TR7 implémente une architecture multi-domaine réseau via l'isolation des tables de routage, le routage cross-domaine, la gestion des processus par table et le cycle de vie piloté par l'interface.
Chaque table de routage possède ses propres routage, interfaces, ARP, pare-feu et namespace de sockets. Les tenants, zones de service ou environnements de test peuvent donc fonctionner sur le même appareil sans interférer les uns avec les autres.
Un seul vService peut écouter des VIP sur plusieurs tables de routage et transférer le trafic vers des backends dans différentes tables de routage. Cela permet un transfert de service contrôlé sans aplatir le réseau.
TR7 peut exécuter un processus de surveillance et de gestion réseau distinct pour chaque table de routage. L'état des liens, les adresses IP, les routes, les statistiques et l'état des services sont collectés indépendamment pour chaque domaine réseau.
Les opérateurs peuvent créer, supprimer, nommer et configurer les paramètres DNS et hosts pour les tables de routage. La table de routage à laquelle appartient une interface peut également être modifiée depuis la console de gestion.
L'Architecture Multi-Namespace rend différents domaines réseau gérables sur un seul ADC — de l'isolation des tenants au routage cross-service.
Une table de routage TR7 n'est pas seulement une liste séparée de routes. L'interface, l'ARP, le pare-feu, les sockets et le comportement des connexions fonctionnent tous indépendamment au sein du domaine. Le comportement réseau d'un tenant ne peut pas déborder sur un autre. Les équipes opérationnelles gèrent plusieurs domaines réseau sur le même appareil de manière plus sécurisée et lisible.
Dans les environnements multi-tenant, différents clients peuvent utiliser les mêmes blocs IP privés. Les tables de routage TR7 maintiennent ces plans d'adresses chevauchants dans des domaines réseau séparés. Le `10.0.0.5` du Tenant A et le `10.0.0.5` du Tenant B peuvent coexister sur le même appareil avec des significations distinctes. Cela donne aux architectures MSP et de cloud souverain une grande flexibilité de planification IP.
Le frontend du vService n'est pas limité à un seul domaine réseau. Le même service peut écouter sur différentes VIP à travers les tables de routage prod, DMZ, gestion ou tenant. Une politique ou sélection de backend différente peut s'appliquer selon la table de routage depuis laquelle le client arrive. Ce modèle simplifie les scénarios de publication multi-réseau sans dupliquer les instances de service.
TR7 peut prendre le trafic arrivant sur une table de routage et le transférer vers un backend dans une table de routage différente. La VIP peut rester dans la DMZ tandis que le backend reste sur le réseau interne ; le réseau tenant peut rester séparé tandis que le réseau de services partagés vit dans sa propre table de routage. Seuls les flux de service autorisés passent par TR7 — les réseaux ne sont jamais fusionnés. La segmentation est préservée tandis que l'accès aux applications est simplifié.
La table de routage à laquelle appartient une interface physique ou virtuelle peut être gérée depuis TR7. C'est pratique lors des migrations, des déplacements de tenants ou des transitions de test à production. L'impact sur les routes, IPs et services lors du déplacement d'une interface doit être évalué complètement. Les équipes opérationnelles n'ont pas à traiter les domaines réseau comme des structures statiques et immuables.
Une paire V-ETH(peer) peut être utilisée pour créer une connexion virtuelle contrôlée entre deux tables de routage différentes. C'est utile lorsque seuls des chemins de trafic spécifiques et définis doivent traverser des domaines autrement entièrement isolés. Applicable aux tests, migrations, partage de services et accès aux services partagés tenant. La connexion reste gouvernée par les politiques TR7 et les règles de pare-feu.
Chaque table de routage peut fonctionner avec ses propres enregistrements DNS et hosts. Le même nom d'hôte peut se résoudre en une IP différente dans différentes tables de routage tenant, ou un environnement de test peut utiliser une résolution de noms différente de la production. Cette séparation réduit les conflits de noms d'hôtes dans les environnements multi-tenant et les scénarios de migration. Les opérateurs gèrent le comportement DNS au niveau du domaine réseau, pas globalement.
Chaque table de routage dynamique peut exécuter son propre processus de routage. Le comportement de routage dynamique BGP, OSPF ou similaire peut être isolé par tenant ou domaine réseau. Un changement de route dans le domaine d'un tenant n'affecte pas le plan de routage d'un autre tenant. C'est un avantage significatif en sécurité et en opérations dans les architectures MSP et d'entreprise multi-régions.
TR7 peut appliquer une gestion séparée du pare-feu pour chaque table de routage. Les règles, ipsets et permissions de trafic opèrent au sein du domaine réseau concerné. Un port ouvert ou une permission accordée pour un tenant n'est pas automatiquement propagée aux services d'un autre tenant. Les équipes de sécurité peuvent définir la portée des politiques de manière plus précise.
Les statistiques de lien, IP, route et trafic peuvent être collectées séparément pour chaque table de routage. Les équipes opérationnelles peuvent voir quel lien, IP ou route pose problème dans quel domaine réseau en isolation. Cette visibilité réduit le temps de dépannage dans les environnements multi-domaines. Les environnements fonctionnant sur un seul appareil sont surveillés dans des vues clairement séparées.
Un health check peut vérifier non seulement si le backend est disponible, mais aussi s'il est accessible depuis la table de routage concernée. Un check émis depuis le domaine réseau frontend vers un backend dans une table de routage différente exerce le chemin de trafic réel — validant le routage, l'ARP et la traversée du pare-feu, pas seulement la disponibilité du service. Cela fournit une confiance opérationnelle critique dans les configurations de routage cross-réseau.
Le comportement multi-table de routage est une partie native de l'architecture réseau de TR7. Les opérateurs n'ont pas besoin de provisionner un appareil virtuel séparé par tenant. L'isolation, le routage et le transfert de service sur le même ADC restent tous dans un seul plan de gestion. Cela réduit à la fois la consommation de ressources et la complexité opérationnelle.
L'architecture multi-tables-de-routage est exploitée avec une gestion complète du cycle de vie, la migration d'interfaces, la récupération de processus, DNS/hosts par table et la coordination d'état cross-domaine.
Lorsqu'un opérateur crée une nouvelle table de routage, TR7 prépare un contexte d'exécution séparé pour ce domaine réseau. Ce domaine porte ses propres comportements d'interface, de route et de pare-feu. Les champs nom et description aident les équipes opérationnelles à distinguer les tenants ou zones de service les uns des autres.
La suppression d'une table de routage qui a encore des interfaces assignées est traitée comme non sécurisée. Le comportement par défaut bloque la suppression jusqu'à ce que les interfaces soient migrées. Si nécessaire, les interfaces peuvent être ramenées vers le domaine par défaut en premier, rendant la suppression contrôlée et explicite.
Si le processus de surveillance et de gestion exécuté pour une table de routage se termine inopinément, il peut être redémarré automatiquement. Cela préserve la continuité du comportement de surveillance multi-domaines. Les équipes opérationnelles ne perdent pas définitivement la visibilité sur un domaine réseau à cause d'une seule défaillance de processus.
Lorsqu'une interface est déplacée d'une table de routage à une autre, l'impact sur les IPs, routes, services et règles de pare-feu doit être évalué ensemble. L'opération est puissante pour les migrations mais doit être planifiée dans les environnements de production. TR7 rend ce comportement visible dans l'interface, réduisant le risque de déplacements non intentionnels.
Une messagerie basée sur les événements peut être établie entre le processus de gestion principal et chaque processus de table de routage. L'état des liens, l'état IP, les informations GTM et les signaux de service sont délivrés séparément à chaque domaine réseau. Cela fournit une coordination contrôlée entre la gestion globale et les domaines réseau isolés.
Une valeur d'index peut être assignée à chaque table de routage. Cet index est utilisé pour dériver les ports de routage dynamique, les offsets d'ID de routeur virtuel et les identifiants de processus auxiliaires par service. Les conflits de ports et d'identités dans plusieurs domaines réseau sont ainsi réduits.
Un MSP peut faire fonctionner plusieurs clients utilisant tous le bloc d'adresses `10.0.0.0/8` sur un seul TR7 ADC, chacun dans sa propre table de routage. Chaque tenant reste isolé dans son propre domaine réseau sans aucun conflit IP.
Les organisations peuvent maintenir la VIP en écoute dans la table de routage DMZ tandis que le backend reste dans la table de routage interne. TR7 ne transporte que le trafic de service autorisé entre les deux domaines — sans les fusionner.
Lorsqu'un service est déplacé d'un ancien réseau tenant vers une nouvelle table de routage, le trafic vService peut être redirigé de manière contrôlée. Le plan IP et l'accès au service sont gérés ensemble tout au long de la migration.
Une table de routage de test peut fonctionner avec des paramètres similaires à la production mais n'a pas d'accès direct au trafic de production. L'équipe opérationnelle peut tester des services spécifiques via le routage cross-table quand nécessaire, tout en préservant l'isolation.
Plans IP chevauchants, routage DMZ vers réseau interne et architecture multi-tenant de tables de routage. Parcourons ensemble une configuration en direct dans votre propre environnement.