Loucuras de Verão com iRules — Parte 2

Rafael Bianco Nacif
TechRebels
Published in
5 min readSep 19, 2019

Syn, syn-ack, ack…

Fala pessoal!! Sejam bem vindos à parte 2 da nossa série sobre iRules! Você pode encontrar todos os meus posts de F5 publicados aqui no TechRebels neste link. Recomendo que sejam lidos na ordem, caso você tenha chegado agora.

E como sempre, fiquem ligados no TechRebels e sigam-me no Medium clicando follow lá em cima para acompanhar os próximos posts.

No primeiro artigo dessa série, introduzimos o conceito de iRules, sua função e funcionamento básico, que sempre gira em torno dos eventos! Como prometido, hoje iremos olhar como adicionar condições para que uma ação de uma iRule seja executada somente se algo for verdadeiro.
Gostaria de destacar aqui antes de começarmos um ponto citado pela leitora Sthefanie Marques, lá no Linkedin:

No comentário ela explica que muitas funções que antes eram implementadas via iRules nas versões antigas do TMOS, hoje são nativas da plataforma nas famosas policys. Além disso, ela destaca também que a F5 não provê suporte a iRules que não tenham sido escritas pela própria F5 (sem a compra de serviços de consultoria). E ela está coberta de razão! Portanto, como mencionei lá no primeiro artigo, se houver uma forma de realizar o que você precisa sem utilizar uma iRule, faça-o!
Obrigado Sthefanie pela lembrança e comentário! =D

E agora, sem mais delongas, como sempre, prepare seu café ou coca-cola geladinha e vamos nessa!

Nessa parte 2 vamos continuar utilizando a mesma topologia do artigo 1 (com algumas alterações de IPs), mas o restante é tudo igual.

BIG-IP em modo standalone rodando TMOS v12.1.4 e um servidor web atrás do BIG-IP. Esse servidor web utiliza o BIG-IP como default-gateway. Temos um virtual-server (VIP) escutando no IP 192.168.15.21 na porta TCP-80.

Recapitulando a primeira iRule que utilizamos, ela ao aceitar a conexão do cliente através do evento “CLIENT_ACCEPTED” executava em seguida o comando “log local0.”, que escrevia uma mensagem no /var/log/ltm.

when CLIENT_ACCEPTED {
log local0. "O BIG-IP aceitou a conexao do cliente"
}

E se você quisesse que essa iRule fosse executada somente se o cliente de IP 192.168.15.211 conectasse?

Toda iRule pode usar a estrutura “if”, ou seja, você pode adicionar uma condição, que se for verdadeira, algo acontece. Vamos adaptar essa iRule com um “if” para ser executada somente se o cliente tiver o IP que desejamos…

when CLIENT_ACCEPTED {
if {[IP::addr [IP::client_addr] equals 192.168.15.211] } {
log local0. "O BIG-IP aceitou a conexao do cliente" }
}

Vamos ler essa iRule em humanês…

Quando o evento “CLIENT_ACCEPTED acontecer, se o endereço IP do cliente for igual a 192.168.15.211, então escreva no /var/log/ltm a mensagem “O BIG-IP aceitou a conexao do cliente”.
A linha que contém o “if” pode parecer confusa, mas observe que:

IP:addr é um valor interno para um IP qualquer.
IP::client_addr é o valor interno para o client-side da conexão em si.
equals é a comparação de igual para um valor especificado por você.

Resumindo, o que o BIG-IP está fazendo é comparar se o valor de IP:addr do client-side da conexão (IP::client_addr) é igual ao valor que você especificou, ou seja, 192.168.15.211.

Agora vamos ver essa parada funcionado… Sim, parada! Eu sou carioca! =D

Eu não sei vocês, mas eu tô curtido demais esses exemplos em vídeo!

As condições “if” podem ser tão simples quanto checar o IP do cliente, mas também podem ser complexas o quanto você quiser! A sua criatividade (e necessidade) é o limite.

Uma outra estrutura muito comum dos “ifs” é o “else”, ou o “senão”. No primeiro “if” você testa uma coisa e se aquela coisa não for verdadeira, você executa uma outra coisa. Vamos a outro exemplo:

when CLIENT_ACCEPTED {
if {[IP::addr [IP::client_addr] equals 192.168.15.211] } {
log local0. "O BIG-IP aceitou a conexao do cliente" }
else {
log local0. "A iRule foi executada com sucesso" }
}

Nessa segunda iRule, adicionamos a estrutura “else”. A estrutura “else” se torna verdadeira quando o “if” é falso, ou seja, no caso do nosso teste, quando o cliente que se conectar não tiver o IP 192.168.15.211. Vamos ver esse segundo caso no lab?

Com esse último exemplo, acredito que tenha ficado bastante claro o cuidado que temos que ter com o evento que utilizamos nas nossas iRules, principalmente em virtual-servers com alto volume de tráfego. Você não precisa ficar apavorado, mas é bom saber por exemplo o quão ocupado o VS que você vai mexer é…

Dica: usem as estatísticas de conexão do próprio BIG-IP e vejam quantas conexões aparecem em 1 hora ou 1 dia. Já é um norte para te guiar…

BÔNUS: No segundo vídeo tem um erro de digitação. Se você achou, comenta aí no artigo e me cobra o café! ;)

As estruturas “if” e “else” são muito comuns nas iRules. Elas podem te auxiliar a afinar ainda mais o teste/verificação que você deseja.

No próximo artigo dessa série vamos ver como utilizar variáveis! É assunto polêmico!

Fiquem ligados aqui no TechRebels! ;)

O que acharam? Gostaram desse novo formato com pequenos videos? Ficaram com alguma dúvida? Não deixe de comentar! Os comentários ajudam a direcionar os próximos artigos! Não deixe de seguir o TechRebels e a mim aqui no Medium clicando no “follow” ali embaixo e também no Twitter!

/FIN=1

Sobre o autor

Rafael Bianco Nacif é analista de redes sênior. Graduado em Redes de Computadores, certificado F5 Solutions Expert Security, Cisco CCNP DC e RS e também AWS CSA. Iniciou a carreira na área de TI como help-desk e hoje atua em projetos de DC de alta complexidade. linkedin.com/in/rafaelbn

--

--

Rafael Bianco Nacif
TechRebels

Senior Network Analyst | Nerd Convicto | 2xF5 CSE (Cloud/Sec), AWS CSA-Associate e CCNP DC/RS