Las decisiones de enrutamiento en el tráfico de aplicaciones empresariales ya no dependen solo del host, la ruta o el puerto. La corrección de headers, la compatibilidad con aplicaciones heredadas, la política CORS, la seguridad de cookies, la limitación de ancho de banda, la activación de captcha, la cuarentena, las páginas de error personalizadas y la transformación de respuestas emergen todas en el mismo camino de tráfico. Las reglas de balanceo de carga simples son insuficientes para satisfacer esta variedad.
La mayoría de los enfoques tradicionales se inclinan hacia uno de dos extremos. O se les da a los operadores solo un puñado de acciones preestablecidas y los casos de uso modernos se vuelven irresolubles, o la flexibilidad total exige escribir scripts en bruto o configuración de bajo nivel. En el segundo modelo, cada cambio de regla se vincula a procesos pesados — desarrollo de software, pruebas, revisión de código y auditoría de seguridad.
El riesgo crece aún más cuando no hay un control claro sobre qué tipo de servicio o fase de tráfico aplica una acción. Escribir una acción de header HTTP en un servicio TCP, esperar un comportamiento de solicitud en el lado de la respuesta, o añadir una acción limitada por pool más de una vez pueden causar problemas en tiempo de ejecución.
El modelo correcto combina un editor visual de reglas con comportamiento de runtime compilado. La GUI debe mostrar solo combinaciones válidas; los metadatos de acción deben gobernar el tipo de servicio y la fase de solicitud/respuesta; y debe permanecer disponible una válvula de escape de regla manual controlada para casos extremos.
El Motor de Reglas de Tráfico TR7 logra este equilibrio: ofrece a los operadores más de 30 acciones listas para usar, oculta las combinaciones inválidas y promueve las reglas correctas al tráfico de producción como configuración validada.
TR7 aplica las reglas de tráfico a través de taxonomía de acciones, conciencia de fase, configuración compilada y un modelo de promoción validado.
Cada acción lleva metadatos para el tipo de servicio, la fase de solicitud/respuesta, el soporte de condiciones, el requisito de contenido, el comportamiento de código de error y el límite de uso por pool. La GUI lee estos metadatos y muestra solo las opciones de regla válidas para el contexto actual.
Las acciones compuestas en el editor visual se emiten en la configuración de trabajo en una secuencia de prioridad definida. La asignación de variables, el enrutamiento, las operaciones de headers, el comportamiento de errores y la selección de backend se ejecutan todos en un orden predecible.
Algunas acciones avanzadas que no pueden expresarse como directivas estáticas se convierten en funciones invocables en tiempo de ejecución. Los operadores pueden gestionar comportamientos de tráfico complejos a través del motor de reglas sin escribir ningún código ellos mismos.
La nueva configuración se genera y luego pasa por un paso de validación. Si la validación falla, la configuración en ejecución actual se preserva y la regla defectuosa nunca llega al tráfico de producción.
El Motor de Reglas de Tráfico combina acciones listas para usar con condiciones FX para ofrecer una aplicación de política controlada a través del camino de solicitudes y respuestas.
TR7 proporciona más de 30 acciones incluyendo add_header, del_header, set_header, replace_header, redirect_scheme, req_redirect_location, set_path, normalize_uri, req_auth, cors, ipMask, cookieEncryption, bandwidthRule, advancedCaptcha, modifyResponse, silentLog, securityHeaders, cookieSecurity, deny, quarantine_table, manualRule y prometheusService. Los operadores seleccionan acciones en el editor visual, completan los parámetros y adjuntan condiciones. Esto elimina las tareas comunes de manipulación de tráfico del dominio del scripting. Los equipos de operaciones producen reglas más rápido y reducen la dependencia de los equipos de desarrollo.
Las acciones se presentan bajo grupos semánticos como atRequest, atResponse, errorRules, cookieBased y tcpRules. Esta separación hace inmediatamente claro en qué fase del tráfico se ejecutará una regla. Las operaciones de header y ruta en el lado de la solicitud no se mezclan con los headers de seguridad y el comportamiento de página de error en el lado de la respuesta. La GUI reduce la complejidad técnica y organiza la creación de reglas por intención.
Cada acción lleva información de compatibilidad para HTTP, TCP o ambos tipos de servicio. Las acciones específicas de HTTP como CORS, la manipulación de headers, la seguridad de cookies y la reescritura de rutas no se muestran para los servicios TCP. Las acciones específicas de TCP como las opciones de gestión de conexiones no se presentan como opciones en un servicio HTTP. Este enfoque evita que los operadores seleccionen una regla que no puede funcionar antes de intentar guardarla.
Los metadatos definen exactamente en qué fase es válida cada acción. Las acciones que deben ejecutarse en la fase de solicitud no pueden vincularse accidentalmente al lado de la respuesta, y las acciones centradas en la respuesta no pueden enlazarse incorrectamente a la ruta de solicitud. Cuando una acción es válida en ambas fases, eso se gestiona explícitamente. Las combinaciones inválidas se detectan durante la validación de configuración antes de que lleguen al tráfico de producción.
Las acciones pueden ejecutarse incondicionalmente o vincularse a condiciones escritas en el lenguaje de expresión FX. La IP de origen, el país, el ASN, la ruta, el header, la cookie, el campo del cuerpo, el rol del usuario, el score WAAP y los valores del temporizador pueden usarse todos en el mismo modelo de condición. Múltiples condiciones se combinan con lógica ACL para determinar cuándo se activa una acción. Esto convierte al motor de reglas en un tomador de decisiones consciente del contexto y del contenido, no solo en una tabla de enrutamiento estática.
Algunas acciones deben aparecer solo una vez en un pool dado. Añadir una segunda instancia de cifrado de cookies, corrección de IP o preservación de nombres de header puede producir resultados inesperados. TR7 lleva el recuento máximo de uso por pool en los metadatos de cada acción y evita que la GUI añada una segunda instancia. Esta protección reduce la inconsistencia operacional antes de que llegue a producción.
Cuando una acción preestablecida no cubre un escenario específico, manualRule permite insertar una regla de tráfico en bruto. Esta característica actúa como válvula de escape para escenarios avanzados fuera del catálogo estándar del motor. Las reglas manuales aún pasan por el paso de validación de configuración y deben usarse con cuidado, ya que afectan el comportamiento del servicio directamente. La plataforma ofrece así tanto la comodidad de reglas visuales como la flexibilidad de nivel avanzado dentro del mismo modelo.
La acción cookieSecurity puede aplicar los atributos de cookie Secure, HttpOnly y SameSite; cookieEncryption puede cifrar los valores de cookie seleccionados en tránsito. La acción cors consolida la lista de origins permitidos, métodos, headers y configuración de caché de preflight bajo una única política. securityHeaders aplica un conjunto de headers de seguridad de base de forma centralizada. quarantine_table coloca una IP específica o una firma de cliente en cuarentena durante un período definido, conteniendo el comportamiento mal reiterado en el edge.
Las reglas de tráfico se operan con promoción atómica, versionado, sincronización de clúster, gestión de conflictos, monitoreo y manejo de casos extremos.
Un nuevo conjunto de reglas se genera por separado y se valida antes de activarse. Si la validación tiene éxito, la configuración activa se intercambia; si falla, la configuración en ejecución actual se preserva. Este modelo ayuda a evitar que una regla defectuosa interrumpa el tráfico de producción.
Cada cambio de regla debe registrarse con una identidad y marca de tiempo. El equipo de operaciones puede ver quién cambió qué regla, qué pool se vio afectado y a qué versión revertir si es necesario. Estos registros tienen particular importancia durante las revisiones de seguridad y cumplimiento.
En despliegues de alta disponibilidad, el mismo conjunto de reglas debe distribuirse a todos los nodos pares. Sin esto, diferentes nodos detrás de la misma VIP pueden mostrar un comportamiento de tráfico diferente. TR7 trata mantener los conjuntos de reglas consistentes en todo el clúster como parte de su modelo operacional.
Cuando más de una acción apunta al mismo header o campo de tráfico, el orden de prioridad es el factor decisivo. El sistema emite las acciones en una secuencia definida; el comportamiento final depende de esa secuencia. Los operadores deben evaluar los posibles conflictos en las reglas críticas usando los registros de auditoría y la lógica de prioridad.
Si las acciones se están ejecutando puede rastrearse a través de silentLog y reenviarse a un SIEM como un campo dedicado. Esto revela cuántas solicitudes coincidieron realmente con una regla, bajo qué condiciones se activó y si produjo el efecto esperado. La observabilidad evita que el motor de reglas se comporte como una caja negra.
Algunos backends heredados son sensibles a las mayúsculas y minúsculas de los nombres de header. La acción keepHeaderNames ayuda a preservar las mayúsculas originales de los nombres de header en esos escenarios de compatibilidad. Esta configuración solo debe usarse en servicios que realmente lo requieran y debe probarse junto con el comportamiento de la aplicación.
Los equipos de modernización pueden usar replace_header o set_header para traducir un nombre de header esperado por un backend heredado a la forma que requiere la aplicación. Se crea una capa de compatibilidad en el punto de entrada del tráfico sin tocar el código de la aplicación.
Los equipos SaaS pueden usar la acción securityHeaders para añadir los headers de seguridad comúnmente requeridos frente a los servicios de forma centralizada. La base de seguridad se fortalece sin que cada equipo de aplicación tenga que configurar los mismos ajustes de forma independiente.
Las aplicaciones financieras pueden combinar las acciones bandwidthRule y advancedCaptcha para activar un desafío captcha después de intentos de login fallidos repetidos. El comportamiento sospechoso repetido se enruta a un flujo de verificación más estricto sin interrumpir completamente la experiencia del usuario.
Los servicios de e-commerce y financieros pueden usar cookieEncryption para entregar las cookies de sesión al cliente de forma cifrada. El backend continúa viendo el valor que espera mientras el contenido de la cookie es ilegible de forma significativa en el lado del cliente.
Control total a través del camino de solicitudes y respuestas con más de 30 acciones listas para usar, condiciones FX y promoción atómica de configuración. Permítanos guiarle por una configuración en vivo sobre sus propios servicios.