En los proyectos tradicionales de despliegue de ADC, el mayor costo no suele ser el propio producto — es remodelar la red existente para adaptarla al producto. Cambiar los gateways predeterminados de los backends, rediseñar los planes de IP, rehacer el comportamiento de las rutas o abrir ventanas de mantenimiento conllevan riesgos significativos en entornos de producción.
En entornos con cientos o miles de backends, el enfoque de "cambiar el gateway de cada servidor" no es viable. Algunos backends pueden no tener ningún gateway definido, otros pueden depender de rutas estáticas y otros pueden ejecutarse en sistemas heredados que son difíciles o imposibles de modificar. En estos casos, insertar un ADC se convierte en un proyecto completo de rediseño de red.
La fusión forzada de segmentos de red es otro problema. El VIP debe estar en la DMZ, el backend debe permanecer en la red interna, las redes de tenants deben permanecer aisladas y el plano de gestión debe mantenerse separado. Si el ADC no puede transportar el tráfico a través de estos dominios de forma controlada, la segmentación de seguridad se rompe o los equipos de aplicación se ven obligados a realizar trabajos innecesarios de migración de IP.
Un único modelo de reverse proxy también falla en cubrir todas las necesidades. Algunas aplicaciones requieren que los backends vean la IP real del cliente; algunos servicios L4 necesitan que el tráfico de retorno eluda el ADC por completo; algunos escenarios inline requieren insertar el ADC sin cambiar IPs ni tocar gateways. Un único modelo basado en NAT no puede abordar este rango de requisitos.
Los Modos de Topología de Despliegue de TR7 proporcionan esta flexibilidad: le permiten elegir la ubicación de tráfico correcta para cada servicio sin tocar las direcciones IP, gateways o asignaciones de Route Table de los backends.
TR7 convierte la topología de despliegue en una decisión arquitectónica que puede adaptarse al tipo de servicio, la ubicación en la red y el riesgo de migración.
En el modelo clásico de reverse proxy, el cliente se conecta a TR7 y TR7 se conecta al backend. En un escenario de transparent bind, el flujo de tráfico se preserva para que el backend vea la IP real del cliente como dirección de origen.
En el modo NAT, tanto la traducción de destino como la de origen se gestionan juntas. En el modo SNAT, solo se ajusta el lado de la fuente. En el modo DR, el tráfico de retorno va directamente al cliente, proporcionando una ruta más eficiente para cargas de trabajo L4 de alto volumen.
La Route Table que aloja el VIP y la Route Table que aloja el backend pueden ser diferentes. TR7 transporta el tráfico entre los dos dominios de red de forma controlada, conectando segmentos DMZ, internos, de tenant y de gestión sin aplanarlos.
TR7 puede tomar posesión del tráfico destinado a IPs de backend específicas y operar inline. La dirección IP, el gateway y la configuración de la aplicación del backend permanecen sin cambios mientras el ADC se inserta en la ruta.
Los Modos de Topología de Despliegue cubren ubicaciones de red que van desde la configuración rápida con una sola interfaz hasta el reenvío L4 de alto throughput.
En el modo one-arm, el tráfico de cliente y backend puede manejarse en el mismo lado de red. TR7 recibe el tráfico del servicio a través de una sola interfaz y lo reenvía al backend relevante usando reglas de enrutamiento. Este modelo es adecuado para un despliegue rápido de ADC con mínimos cambios en la red. Es un punto de partida práctico para despliegues piloto, transiciones temporales o escenarios de implantación de bajo riesgo.
En el modo two-arm, TR7 se posiciona entre dos segmentos de red distintos. Un lado enfrenta la red del cliente o la DMZ; el otro enfrenta la red del backend. Esto convierte al ADC no solo en un reenviador de tráfico sino en un punto de tránsito que aplica políticas en el límite de la red. Es adecuado para arquitecturas empresariales que requieren seguridad y segmentación.
En el modo reverse proxy, el cliente se conecta al VIP o vService en TR7, y TR7 abre una conexión separada al backend. La terminación TLS, WAAP, manipulación de cabeceras, seguridad de cookies, reglas conscientes del contenido e integración con AAM son todos totalmente aplicables en este modo. Esta es la topología de entrega de aplicaciones más común para tráfico HTTP y API. Los backends nunca quedan expuestos directamente a internet o redes externas.
En un escenario transparent L7, la IP de origen que ve el backend es la dirección real del cliente en lugar de la dirección del ADC. Este modo es valioso para aplicaciones que no pueden depender únicamente del reenvío de IP de cliente basado en cabeceras. Los logs, el control de acceso y las decisiones basadas en IP dentro de la aplicación funcionan de forma más natural. La ruta de retorno de la red debe planificarse en consecuencia.
El modo Bridge permite que TR7 se sitúe en la ruta de tráfico como un bridge de Capa 2. En este escenario se reduce la necesidad de renumeración de IPs adicional o cambios de enrutamiento amplios. La direccionamiento existente puede preservarse al entrar en la ruta de tráfico entre VMs, contenedores o segmentos. El modo Bridge es útil en entornos donde los cambios en la red deben mantenerse al mínimo.
En el modo transparent gateway, TR7 se posiciona en el punto de tránsito de la red del backend. La IP de origen se preserva y no se requiere NAT. Este modo es valioso en escenarios donde los backends deben ver la IP del cliente de forma natural. Los cambios de ruta predeterminada deben planificarse cuidadosamente y la ruta de retorno debe controlarse explícitamente.
TR7 puede tomar posesión del tráfico para IPs de backend designadas y operar inline. Este modo es particularmente valioso cuando la dirección IP, el gateway predeterminado o las configuraciones de ruta de un backend no pueden cambiarse. Incluso cuando el backend no tiene ningún gateway configurado, TR7 puede posicionarse como el punto de control en la ruta de tráfico relevante. En entornos grandes, la inserción inline controlada reemplaza la necesidad de modificar cientos de backends individualmente.
TR7 puede escuchar en un VIP en una Route Table y reenviar el tráfico a un backend en una Route Table diferente. Esto permite que las zonas DMZ, internas, de tenant, de gestión y de servicio distintas se conecten entre sí de forma controlada sin ser movidas al mismo plano de red. Los operadores no necesitan renumerar backends ni aplanar redes. TR7 se convierte en un punto de tránsito controlado entre Route Tables donde se puede aplicar la política de seguridad.
En el modo L4 NAT, la traducción de destino y de origen se usan juntas para garantizar la ruta de retorno a través de TR7. En el modo SNAT, solo se ajusta el lado de la fuente y se respeta el diseño de ruta de retorno existente del backend. Estos dos modos permiten transportar el tráfico L4 de una manera que se adapta a la topología de red. Se puede seleccionar un comportamiento separado para UDP, TCP o rangos de puertos específicos.
En el modo DR, el tráfico de solicitudes se reenvía al backend a través de TR7 mientras el tráfico de respuestas regresa directamente al cliente. Este modelo es ventajoso para servicios L4 de streaming de alto volumen, gaming, DNS o sensibles a la latencia. Dado que el ADC no transporta el tráfico de retorno, la ruta de datos se vuelve más eficiente. El comportamiento del backend y de la red de retorno debe prepararse correctamente para los escenarios DR.
La persistencia L4 ayuda a garantizar que el tráfico de un cliente específico permanezca en el mismo destino de backend. CONNMARK, registros recientes y una ventana de persistencia configurable mantienen la continuidad del flujo. La persistencia SIP proporciona comportamiento especializado para protocolos sensibles a la sesión como el tráfico SIP. Esto aporta consistencia de sesión a nivel L4 además de la distribución básica de carga.
Los permisos de ingreso requeridos para las definiciones de L4 y vService pueden generarse automáticamente. Se crean reglas de aceptación apropiadas para cada IP de frontend, puerto y protocolo, reduciendo los errores manuales de firewall. La generación automática de reglas es especialmente importante en escenarios inline y L4. El operador selecciona la topología; TR7 genera consistentemente los permisos básicos para la ruta de tráfico relevante.
Los modos de topología se operan junto con los valores predeterminados L4, el comportamiento del proceso inline, las Route Tables de TR7, el rol del clúster y la visibilidad de errores.
El algoritmo round-robin, el modo NAT y el protocolo UDP están disponibles como valores de inicio predeterminados para un nuevo pool L4. Los operadores pueden cambiarlos a TCP, UDP, cualquier protocolo, rango de puertos u otro algoritmo L4 según los requisitos del servicio. Los valores predeterminados están pensados para un inicio rápido; el comportamiento en producción debe revisarse explícitamente.
Algoritmos como round-robin y weighted round-robin pueden usarse para la distribución L4. El modelo ponderado proporciona una distribución de tráfico más equilibrada entre backends con diferentes capacidades. La selección del algoritmo debe planificarse junto con el tipo de servicio, la capacidad y el comportamiento de la sesión.
El modo IP-takeover inline opera basándose en la interfaz relevante, la IP del backend y la información del gateway. Si no se especifica un gateway explícitamente, la ruta apropiada puede derivarse de la información de red existente. Si el proceso se detiene inesperadamente, se puede aplicar el reinicio automático.
En el modo inline, condiciones como noBackendIp, ipUsed, noZoneId, noMatchingIp, noSpoofingIp, inactiveClusterDevice e inactiveClusterIp pueden mostrarse como razones de error explícitas. Esto le dice al equipo de operaciones exactamente por qué algo no funciona en lugar de simplemente que no funciona. La visibilidad de errores es crítica para operar topologías inline de forma segura.
En un entorno de clúster, el proceso de takeover inline debe ejecutarse solo en el dispositivo que tiene el rol activo. Cuando el dispositivo activo cambia, la propiedad del tráfico inline se mueve al nodo relevante. Este modelo ayuda a evitar que dos nodos reclamen simultáneamente la propiedad de la misma IP.
El modo transparent inline reduce la dependencia de la configuración del gateway predeterminado del backend. Si el backend no tiene gateway o el gateway no puede cambiarse, TR7 puede tomar la ruta de tráfico relevante usando el método IP-takeover. Esta capacidad permite el despliegue controlado del ADC sin abrir ventanas de mantenimiento ni modificar backends.
La Route Table de TR7 en la que escucha el VIP y la Route Table de TR7 donde reside el backend pueden ser diferentes. TR7 transporta el tráfico entre estos dos dominios de red, reduciendo la necesidad de cambios topológicos. Este comportamiento es particularmente valioso para la transición controlada desde la DMZ a la red interna, desde la red de tenant a la red de servicio compartido, o entre dominios de red antiguos y nuevos durante una migración.
En organizaciones grandes, cambiar la IP, la ruta o el gateway de cientos de backends implica un alto riesgo. El modo IP-takeover inline permite insertar TR7 ADC en la ruta de tráfico mientras se preserva el direccionamiento existente.
Algunos backends heredados o aislados pueden no tener ningún gateway predeterminado configurado. En el modo transparent inline, TR7 puede tomar el tráfico relevante sin tocar la configuración del gateway del backend.
Las organizaciones pueden escuchar VIPs en una Route Table de DMZ mientras mantienen los backends en una Route Table interna. TR7 proporciona tránsito de tráfico controlado entre los dos dominios sin fusionar redes ni renumerar IPs de servicio.
Los equipos de gaming o streaming pueden usar el modo DR para enviar el tráfico de respuesta directamente al cliente. Mientras TR7 toma la decisión de reenvío, se reduce la carga en la ruta de datos de retorno y los escenarios de alto throughput se vuelven más eficientes.
Desde one-arm hasta transparent inline, L4 DR hasta reenvío cross-Route-Table — exploremos la topología correcta en una configuración en vivo.