Desplegar un ADC no debería requerir cambiar las direcciones IP, gateways o segmentos de red de los backends.
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.
Nuestro enfoque
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.
Reverse proxy L7 y transparent bind se soportan conjuntamente
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.
Los modos L4 NAT, SNAT y DR ofrecen rutas de retorno distintas
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.
El reenvío cross-Route-Table conecta segmentos sin fusionarlos
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.
IP-takeover inline inserta el ADC sin modificar los servicios existentes
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.
Capacidades
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.
El modo one-arm route-mode permite un despliegue rápido con una sola interfaz
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.
El modo two-arm gateway-mode impone la separación entre DMZ y red interna
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.
El modo reverse proxy entrega el comportamiento clásico de vService L7
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.
Transparent L7 bind preserva la IP real del cliente en el backend
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 L2 Bridge reduce los cambios en la Capa 3
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.
Transparent gateway proporciona tránsito inline sin NAT
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.
IP-takeover inline inserta el ADC sin cambiar gateways
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.
El reenvío cross-Route-Table conecta servicios sin fusionar redes
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.
Los modos L4 NAT y SNAT se seleccionan según la ruta de retorno requerida
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.
El modo L4 DR transporta el tráfico de retorno de alto volumen directamente
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 y la persistencia SIP mantienen la continuidad de sesión
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.
La generación automática de reglas de seguridad simplifica el acceso al servicio
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.
Profundidad operacional
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.
Comportamiento predeterminado L4
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.
Selección de algoritmo L4
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.
Proceso de takeover inline
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.
Razones de error inline
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.
Comportamiento inline consciente del clúster
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.
Independencia del gateway predeterminado
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.
Reenvío cross-Route-Table
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.
Cuándo utilizarlo
Despliegue inline sin tocar los backends
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.
Insertar el ADC para servicios que no tienen gateway
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.
Tránsito de servicio controlado entre Route Tables distintas
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.
Tráfico L4 de gaming y streaming de alto volumen
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.
Preguntas frecuentes
¿Qué modos de topología de despliegue soporta TR7?
¿Cómo funciona el modo IP-takeover inline?
¿Cuál es la diferencia entre los modos L4 NAT, SNAT y DR?
¿Qué proporciona el reenvío cross-Route-Table?
¿Qué razones de error pueden monitorizarse en el modo inline?
¿Cuándo debería preferirse el modo one-arm sobre el two-arm?
Adapte TR7 a su red existente — sin tocar sus backends
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.