iRules

Resumen

Una iRule es un script (TCL con extensiones de F5) que se asigna a un virtual server y se ejecuta cuando ocurre un evento del tráfico: llega una conexión, llega una petición HTTP, se elige un miembro… Sirve para lo que la configuración normal no cubre: elegir pool según la URL, redirigir, insertar headers, aplicar SNAT o persistencia a cierto tráfico, registrar información. Si una Local Traffic Policy puede hacerlo, es preferible la policy (Local Traffic Policies).

Requisitos previos

• VS con los perfiles que la iRule necesita (HTTP para eventos HTTP_*, Client SSL para CLIENTSSL_*)
• Pools, data groups o perfiles de persistencia que la iRule mencione
• Probar primero en el lab

Conceptos clave

Concepto	Qué es
when EVENTO { … }	Cuándo se ejecuta (CLIENT_ACCEPTED, HTTP_REQUEST, HTTP_RESPONSE, LB_SELECTED, LB_FAILED…)
Comandos	pool, node, snat, persist, HTTP::redirect, HTTP::respond, HTTP::header, reject, drop, log local0.
HTTP::host / HTTP::uri	Dominio pedido / ruta y query (/index.php?id=123)
IP::client_addr / IP::remote_addr	IP del cliente
Data group	Lista (IPs, textos) que la iRule consulta con class match
Priority	Orden entre varias iRules del mismo evento

Dependencias de perfiles

Una iRule con HTTP_REQUEST en un VS sin perfil HTTP genera error y resetea conexiones. CLIENT_ACCEPTED + IP::client_addr es capa 4: funciona sin perfil HTTP (con TCP o UDP).

Configuración (Ejemplo, Lab CBT Nuggets)

1. Crear una iRule

Local Traffic > iRules > iRule List > Create > Name > pega el código > Finished.

2. Asignarla al VS

Virtual Servers > el VS > Resources > iRules > Manage > pásala de Available a Enabled > Finished.

tmsh modify ltm virtual VS-172.16.101.20-HTTP-APP1 rules { X-Forward-For-iRULE }

3. Ejemplos del curso

Insertar la IP real del cliente (cuando hay SNAT):

when HTTP_REQUEST {
    HTTP::header insert X-Forwarded-For [IP::remote_addr]
}

Mandar un cliente concreto a un pool (capa 4):

when CLIENT_ACCEPTED {
    if { [IP::client_addr] equals "172.16.101.5" } {
        pool HTTP_APP1_Pool
    }
}

Persistencia solo para un dominio (usa HTTP::host, no HTTP::uri):

when HTTP_REQUEST {
    if { [string tolower [HTTP::host]] contains "company.com" } {
        persist source_addr
    }
}

4. Ejemplos de uso diario

Redirigir HTTP a HTTPS (también existe la iRule incluida _sys_https_redirect):

when HTTP_REQUEST {
    HTTP::redirect "https://[HTTP::host][HTTP::uri]"
}

Enviar /api a otro pool:

when HTTP_REQUEST {
    if { [HTTP::uri] starts_with "/api" } {
        pool pool_api
    }
}

Bloquear clientes que no están en una lista permitida (data group redes_permitidas):

when CLIENT_ACCEPTED {
    if { not [class match [IP::client_addr] equals redes_permitidas] } {
        reject
    }
}

Depurar (escribe en /var/log/ltm):

when HTTP_REQUEST {
    log local0. "Cliente [IP::client_addr] pidió [HTTP::host][HTTP::uri]"
}

Verificación

Comando o lugar	Qué debes ver	Si no lo ves
Local Traffic > iRules > la iRule > Statistics	Ejecuciones (Executions), fallos y abortos	No está asignada o el evento no ocurre
tmsh show ltm rule X-Forward-For-iRULE	Lo mismo por CLI	—
tail -f /var/log/ltm	Mensajes de log local0. y errores TCL	Revisa sintaxis
tmsh list ltm virtual <vs> rules	La iRule asignada	Paso 2

Errores comunes

Error “TCL error” y conexiones reseteadas

• Causa: comando HTTP en un VS sin perfil HTTP, variable no definida o error de sintaxis.
• Revisa: /var/log/ltm.
• Solución: agrega el perfil necesario o corrige el código.

La iRule no hace nada

• Causa: no está asignada al VS, el evento no aplica (ej. HTTP_REQUEST sin HTTP) o la condición nunca se cumple (uri vs host).
• Solución: agrega un log local0. temporal para ver los valores reales.

El CPU del BIG-IP subió después de agregar una iRule

• Causa: lógica pesada en cada petición o mucho logging.
• Solución: simplifica, usa data groups, pasa a una policy si es posible, quita los logs.

Dos iRules chocan

• Causa: ambas eligen pool o redirigen en el mismo evento.
• Solución: ordénalas con priority o únelas en una.