Dans les projets de déploiement ADC traditionnels, le coût le plus élevé n'est généralement pas le produit lui-même — c'est la réorganisation du réseau existant pour l'adapter au produit. Modifier les gateways par défaut des backends, reconfigurer les plans IP, retravailler le comportement de routage ou ouvrir des fenêtres de maintenance comporte tous des risques significatifs en environnements de production.
Dans les environnements avec des centaines ou des milliers de backends, l'approche "modifier la gateway de chaque serveur" n'est pas viable. Certains backends peuvent n'avoir aucune gateway définie, d'autres peuvent reposer sur des routes statiques, et d'autres encore peuvent tourner sur des systèmes historiques difficiles ou impossibles à modifier. Dans ces cas, insérer un ADC devient un projet complet de refonte réseau.
La fusion forcée de segments réseau est un autre problème. Le VIP doit se trouver dans la DMZ, le backend doit rester sur le réseau interne, les réseaux locataires doivent rester isolés, et le plan de gestion doit être maintenu séparé. Si l'ADC ne peut pas transporter le trafic à travers ces domaines de manière contrôlée, la segmentation sécurité se dégrade ou les équipes applicatives sont forcées vers un travail de migration IP inutile.
Un seul modèle reverse proxy échoue également à couvrir chaque besoin. Certaines applications nécessitent que les backends voient la vraie IP client ; certains services L4 ont besoin que le trafic de retour contourne entièrement l'ADC ; certains scénarios inline nécessitent d'insérer l'ADC sans changer les IPs ni toucher aux gateways. Un seul modèle basé sur NAT ne peut pas adresser cette gamme d'exigences.
Les Modes de Topologie de Déploiement de TR7 fournissent cette flexibilité : ils vous permettent de choisir le bon placement de trafic pour chaque service sans toucher aux adresses IP, gateways ou assignations de Route Table des backends.
TR7 transforme la topologie de déploiement en une décision architecturale qui peut être adaptée au type de service, au placement réseau et au risque de migration.
Dans le modèle reverse proxy classique, le client se connecte à TR7 et TR7 se connecte au backend. Dans un scénario de transparent bind, le flux de trafic est préservé de sorte que le backend voit la vraie IP client comme adresse source.
En mode NAT, la traduction de destination et de source sont gérées ensemble. En mode SNAT, seul le côté source est ajusté. En mode DR, le trafic de retour va directement au client, offrant un chemin plus efficace pour les charges de travail L4 à fort volume.
La Route Table hébergeant le VIP et la Route Table hébergeant le backend peuvent être différentes. TR7 transporte le trafic entre les deux domaines réseau de manière contrôlée, connectant les segments DMZ, interne, locataire et gestion sans les aplatir.
TR7 peut prendre en charge le trafic destiné à des IPs backend spécifiques et opérer inline. L'adresse IP, la gateway et la configuration applicative du backend restent inchangées pendant que l'ADC est inséré dans le chemin.
Les Modes de Topologie de Déploiement couvrent les placements réseau allant d'une configuration rapide à interface unique jusqu'au forwarding L4 à haut débit.
En mode one-arm, le trafic client et backend peut être géré du même côté réseau. TR7 reçoit le trafic de service via une seule interface et le transfère au backend pertinent en utilisant des règles de routage. Ce modèle convient à un déploiement ADC rapide avec un minimum de changements réseau. C'est un point de départ pratique pour les déploiements pilotes, les transitions temporaires ou les scénarios à faible risque.
En mode two-arm, TR7 est positionné entre deux segments réseau distincts. Un côté fait face au réseau client ou DMZ ; l'autre fait face au réseau backend. Cela fait de l'ADC non seulement un transmetteur de trafic mais un point de transit appliquant la politique à la frontière réseau. Il convient aux architectures d'entreprise nécessitant sécurité et segmentation.
En mode reverse proxy, le client se connecte au VIP ou vService sur TR7, et TR7 ouvre une connexion séparée au backend. La terminaison TLS, WAAP, la manipulation des headers, la sécurité des cookies, les règles content-aware et l'intégration AAM sont tous pleinement applicables dans ce mode. C'est la topologie de livraison d'applications la plus courante pour le trafic HTTP et API. Les backends ne sont jamais exposés directement à internet ou aux réseaux externes.
Dans un scénario de transparent L7, l'IP source vue par le backend est la vraie adresse client plutôt que l'adresse ADC. Ce mode est précieux pour les applications qui ne peuvent pas se fier uniquement au forwarding IP client basé sur header. Les logs, le contrôle d'accès et les décisions basées sur IP dans l'application fonctionnent plus naturellement. Le chemin de retour réseau doit être planifié en conséquence.
Le mode Bridge permet à TR7 de s'insérer dans le chemin de trafic comme un pont Layer 2. Dans ce scénario, le besoin de renumérotation IP supplémentaire ou de changements de routage étendus est réduit. L'adressage existant peut être préservé lors de l'entrée dans le chemin de trafic sur des VMs, conteneurs ou segments. Le mode Bridge est utile dans les environnements où les changements réseau doivent être minimisés.
En mode transparent gateway, TR7 est positionné au point de transit du réseau backend. L'IP source est préservée et le NAT n'est pas requis. Ce mode est précieux dans les scénarios où les backends doivent voir l'IP client naturellement. Les changements de route par défaut doivent être planifiés soigneusement et le chemin de retour doit être explicitement contrôlé.
TR7 peut prendre en charge le trafic pour des IPs backend désignées et opérer inline. Ce mode est particulièrement précieux lorsque l'adresse IP, la gateway par défaut ou les paramètres de route d'un backend ne peuvent pas être modifiés. Même lorsque le backend n'a aucune gateway configurée, TR7 peut se positionner comme point de contrôle dans le chemin de trafic pertinent. Dans les grands environnements, l'insertion inline contrôlée remplace le besoin de modifier des centaines de backends individuellement.
TR7 peut écouter sur un VIP dans une Route Table et transmettre le trafic à un backend dans une Route Table différente. Cela permet aux zones DMZ, internes, locataires, de gestion et de services distincts d'être connectées entre elles de manière contrôlée sans être déplacées vers le même plan réseau. Les opérateurs n'ont pas besoin de renuméroter les backends ni d'aplatir les réseaux. TR7 devient un point de transit contrôlé entre les Route Tables où la politique de sécurité peut être appliquée.
En mode L4 NAT, la traduction de destination et de source sont utilisées ensemble pour garantir le chemin de retour via TR7. En mode SNAT, seul le côté source est ajusté, et la conception du chemin de retour existant du backend est respectée. Ces deux modes permettent au trafic L4 d'être transporté d'une façon qui s'adapte à la topologie réseau. Un comportement séparé peut être sélectionné pour UDP, TCP ou des plages de ports spécifiques.
En mode DR, le trafic de requête est transmis au backend via TR7 pendant que le trafic de réponse retourne directement au client. Ce modèle est avantageux pour les services L4 à fort volume de streaming, jeux, DNS ou sensibles à la latence. Parce que l'ADC ne transporte pas le trafic de retour, le chemin de données devient plus efficace. Le comportement de retour du backend et du réseau doit être préparé correctement pour les scénarios DR.
La persistance L4 aide à garantir que le trafic d'un client spécifique reste sur la même cible backend. CONNMARK, les enregistrements récents et une fenêtre de persistance configurable maintiennent la continuité des flux. La persistance SIP fournit un comportement spécialisé pour les protocoles sensibles à la session comme le trafic SIP. Cela apporte une cohérence de session au niveau L4 en plus de la distribution de charge basique.
Les permissions d'entrée requises pour les définitions L4 et vService peuvent être générées automatiquement. Des règles d'acceptation appropriées sont créées pour chaque IP frontend, port et protocole, réduisant les erreurs manuelles de firewall. La génération automatique de règles est particulièrement importante dans les scénarios inline et L4. L'opérateur sélectionne la topologie ; TR7 génère de manière cohérente les permissions de base pour le chemin de trafic pertinent.
Les modes de topologie sont opérés avec les valeurs par défaut L4, le comportement du processus inline, les Route Tables TR7, le rôle cluster et la visibilité des erreurs.
L'algorithme round-robin, le mode NAT et le protocole UDP sont disponibles comme valeurs de démarrage par défaut pour un nouveau pool L4. Les opérateurs peuvent les modifier vers TCP, UDP, tout protocole, plage de ports ou un algorithme L4 différent selon les exigences du service. Les valeurs par défaut sont destinées à un démarrage rapide ; le comportement en production doit être revu explicitement.
Des algorithmes comme round-robin et round-robin pondéré peuvent être utilisés pour la distribution L4. Le modèle pondéré fournit une distribution de trafic plus équilibrée entre les backends avec des capacités différentes. La sélection d'algorithme doit être planifiée avec le type de service, la capacité et le comportement de session.
Le mode IP-takeover inline opère selon l'interface pertinente, l'IP backend et les informations de gateway. Si une gateway n'est pas explicitement spécifiée, le chemin approprié peut être déduit des informations réseau existantes. Si le processus s'arrête inopinément, un redémarrage automatique peut être appliqué.
En mode inline, des conditions comme noBackendIp, ipUsed, noZoneId, noMatchingIp, noSpoofingIp, inactiveClusterDevice et inactiveClusterIp peuvent être présentées comme raisons d'erreur explicites. Cela indique à l'équipe opérationnelle précisément pourquoi quelque chose ne fonctionne pas plutôt que simplement que cela ne fonctionne pas. La visibilité des erreurs est critique pour opérer les topologies inline en toute sécurité.
Dans un environnement cluster, le processus de prise en charge inline ne doit s'exécuter que sur le dispositif qui détient le rôle actif. Lorsque le dispositif actif change, la propriété du trafic inline se déplace vers le nœud pertinent. Ce modèle aide à empêcher deux nœuds de revendiquer simultanément la propriété de la même IP.
Le mode transparent inline réduit la dépendance au paramètre de gateway par défaut du backend. Si le backend n'a pas de gateway ou que la gateway ne peut pas être modifiée, TR7 peut prendre en charge le chemin de trafic pertinent en utilisant la méthode IP-takeover. Cette capacité permet un déploiement ADC contrôlé sans ouvrir de fenêtres de maintenance ni modifier les backends.
La Route Table TR7 sur laquelle le VIP écoute et la Route Table TR7 où réside le backend peuvent être différentes. TR7 transporte le trafic entre ces deux domaines réseau, réduisant le besoin de changements de topologie. Ce comportement est particulièrement précieux pour la transition contrôlée de DMZ vers réseau interne, de réseau locataire vers réseau de services partagés, ou entre anciens et nouveaux domaines réseau lors d'une migration.
Dans les grandes organisations, modifier l'IP, la route ou la gateway de centaines de backends est à haut risque. Le mode IP-takeover inline permet à TR7 ADC d'être inséré dans le chemin de trafic pendant que l'adressage existant est préservé.
Certains backends historiques ou isolés peuvent n'avoir aucune gateway par défaut configurée. En mode transparent inline, TR7 peut prendre en charge le trafic pertinent sans toucher au paramètre de gateway du backend.
Les organisations peuvent écouter les VIPs sur une Route Table DMZ tout en gardant les backends sur une Route Table interne. TR7 fournit un transit de trafic contrôlé entre les deux domaines sans fusionner les réseaux ni renuméroter les IPs de service.
Les équipes jeux ou streaming peuvent utiliser le mode DR pour envoyer le trafic de réponse directement au client. Pendant que TR7 prend la décision de forwarding, la charge sur le chemin de données de retour est réduite et les scénarios à haut débit deviennent plus efficaces.
De one-arm à transparent inline, de L4 DR au forwarding cross-Route-Table — laissez-nous parcourir la bonne topologie dans une configuration en direct.