Uma iRule é um conjunto de handlers de eventos. Você escreve blocos como when HTTP_REQUEST { ... }, e o BIG-IP executa cada bloco quando o evento dele dispara. Os eventos não são arbitrários — eles disparam em uma sequência específica que espelha como uma conexão é de fato processada, e quais eventos aparecem depende de quais perfis estão anexados ao virtual server.

O caminho feliz, de ponta a ponta

Para um virtual server HTTPS completo que recriptografa para o pool (um perfil Client-SSL, um perfil HTTP, um perfil Server-SSL e um pool), os eventos comuns disparam nesta ordem:

CLIENT_ACCEPTED        conexão TCP do cliente estabelecida
CLIENTSSL_CLIENTHELLO  ClientHello TLS do cliente recebido
CLIENTSSL_HANDSHAKE    handshake TLS do lado cliente concluído
HTTP_REQUEST           cabeçalhos completos da requisição analisados
LB_SELECTED            membro do pool escolhido
SERVER_CONNECTED       conexão ao membro estabelecida
SERVERSSL_HANDSHAKE    handshake TLS do lado servidor concluído
HTTP_REQUEST_SEND      prestes a enviar a requisição ao servidor
HTTP_RESPONSE          status e cabeçalhos da resposta analisados
SERVER_CLOSED          conexão do lado servidor encerrada
CLIENT_CLOSED          conexão do lado cliente encerrada

Remova um perfil e os eventos relacionados simplesmente somem. Tire o perfil HTTP e você fica com um fluxo TCP puro: CLIENT_ACCEPTED, LB_SELECTED, SERVER_CONNECTED, SERVER_CLOSED, CLIENT_CLOSED. Tire o pool e não há para onde balancear, então LB_SELECTED e todos os eventos do lado servidor desaparecem.

Por que a ordem importa

A ordem não é trivialidade — ela dita quais dados estão disponíveis e quando. HTTP::header funciona em HTTP_REQUEST porque os cabeçalhos já foram analisados àquela altura; chamá-lo em CLIENT_ACCEPTED dá erro, porque nesse ponto o BIG-IP tem uma conexão TCP e nada mais. Comandos de seleção de pool pertencem antes de LB_SELECTED; comandos de resposta só fazem sentido de HTTP_RESPONSE em diante. Boa parte dos erros de execução de iRule é, na verdade, um erro de ordem de evento — tocar em algo que ainda não existe.

Um mapa, não o território

Esta ferramenta modela a ordem documentada para um virtual server Standard (full-proxy), que cobre a grande maioria dos casos de uso de BIG-IP LTM - Local Traffic Manager. O conjunto exato também depende de módulos: BIG-IP Zero Trust Access (antigo BIG-IP APM - Access Policy Manager), F5 AWAF - Advanced WAF (antigo BIG-IP ASM - Application Security Manager) e outros adicionam seus próprios eventos. Também depende de a sua iRule coletar dados explicitamente. Use-a para raciocinar sobre onde no fluxo a sua lógica deve viver, e depois confirme contra uma configuração real para qualquer coisa incomum.