Guia de Sobrevivência BIG-IP — Parte 1
Syn, syn-ack, ack mundo! Meu nome é Rafael e essa será uma série de artigos sobre o funcionamento básico e arquitetura dos balanceadores de carga da F5, o famoso BIG-IP! Iremos construir, tijolinho a tijolinho, um entendimento de como essa plataforma é estruturada, desde os serviços mais básicos até conceitos mais complicados. Fique ligado no TechRebels e siga-me aqui no Medium para acompanhar as próximas partes. Vem comigo!
A F5 fornece atualmente o BIG-IP em diversas plataformas: appliance físico, caixas Viprion (chassis modulares) e também edições virtuais que podem rodar em cima de variados hypervisors. Mas, independentemente da plataforma, todos são construídos em cima do TMOS (Traffic Management Operating System). E a vantagem disso é uma experiência de GUI e CLI idêntica para nós administradores!
O TMOS por sua vez, apesar do nome de sistema operacional, na verdade é um grande programa (ou uma coleção de módulos) que roda em cima do Kernel Linux. Isso mesmo! Os BIG-IPs são “servidores” Linux altamente customizados que rodam o TMOS como um serviço como outro qualquer.
Durante a sequência de boot do BIG-IP, a aplicação TMOS (ou TMM) é executada, e o processo entra em memória e passa a estar presente no user space do Linux:
Então, estabelecemos agora que os BIG-IPs em sua fundação são “servidores” especializados que rodam em cima de um Linux. Isso já deveria te dar outra pista: grande parte das ferramentas para um troubleshoot presentes em um Linux também estão à sua disposição no BIG-IP: ping, traceroute, dig, telnet, nc, curl, tail, grep e outros muitos mais!
AVISO: Apesar de ser construído em cima de um Linux, a F5 recomenda fortemente que você não altere arquivos de configuração do Linux ou faça modificações no Linux sem o intermédio do TMOS.
Agora que você sabe que o BIG-IP não é tão estranho quanto você achava que era, essas são as duas principais regras de ouro para se lembrar quando se começa a trabalhar com esse equipamento:
1. O BIG-IP é um full-proxy.
2. O BIG-IP é um default deny por padrão.
Full Proxy — Para fluxos balanceados, o BIG-IP por padrão irá sempre sustentar um par de conexões: uma entre o cliente que fez o acesso e o BIG-IP, e outra entre o BIG-IP e o servidor balanceado em si. Vamos a uma imagem que mostra isso muito melhor:
Isso é um grande diferencial, pois a partir do momento em que o cliente se conecta (executa um 3-way-handshake) diretamente com o BIG-IP, é possível executar diversas transformações desse tráfego dentro do BIG-IP. O céu é o limite com a quantidade de coisas que podemos fazer!
Default Deny — Por padrão, o BIG-IP nunca irá aceitar um tráfego. Você como administrador precisa dizer a ele que aquele tráfego deve ser processado, seja ele balanceado ou roteado. E isso é feito com um dos vários objetos dentro do ambiente TMOS: os virtual servers! Por exemplo, se você quer balancear um site http qualquer, certamente teremos que ter um objeto de virtual server escutando no IP do site com a porta TCP/80 habilitado dentro do BIG-IP. Sem isso, por mais que o tráfego chegue ao BIG-IP, ele nunca será processado. Essa decisão por parte da F5 tem como principal motivador a segurança. Muitos BIG-IPs possuem conectividade direta com a Internet e, por isso, existe uma preocupação muito grande em manter o sistema o mais seguro possível.
Vamos citar um exemplo agora que leva essas duas regras em consideração. Com a mesma topologia de antes — agora com endereços IPs — vamos construir um fluxo dessa comunicação.
1. Cliente aponta o browser para o IP do virtual server balanceado cujo IP é 172.16.0.1 na porta TCP 80.
a. Se esse mesmo cliente enviasse tráfegos para a porta TCP 443, esse fluxo nunca seria processado pelo BIG-IP pois não há um virtual server configurado com essa combinação de IP e porta. Essa é a regra de ouro 2 em ação!
2. BIG-IP retorna o SYN-ACK cujo IP de origem é o IP do virtual server (172.16.0.1) e o IP de destino é o cliente (10.0.0.1).
3. O cliente devolve um ACK finalizando o 3-way-handshake.
4. A primeira parte da conexão full proxy é estabelecida e então o cliente começa a enviar dados (nesse caso, um GET http para o BIG-IP).
5. O BIG-IP detecta que para aquele virtual server que ele acabou de receber uma conexão, o servidor que receberá a próxima conexão é o servidor 192.168.0.10.
a. O BIG-IP então envia um SYN para o servidor. Esse pacote SYN possui IP de origem do cliente (nesse cenário estamos utilizando um design em L3, em que os servidores utilizam o BIG-IP como default gateway) e o IP de destino é o do servidor balanceado 192.168.0.10.
6. O servidor responde ao BIG-IP o SYN-ACK.
7. O BIG-IP finaliza o 3-way-handshake com o ACK e estabelece então a conexão.
a. Repare que aqui, o “cliente” dessa parte da conexão na verdade é o BIG-IP!
8. O segundo par de conexão da arquitetura full proxy é estabelecido. Temos agora uma conexão entre o cliente original e o BIG-IP (passo 4, lado esquerdo da imagem) e outra conexão entre o BIG-IP e o servidor balanceado (passo 8, lado direito).
9. A partir desse momento, todas as solicitações do cliente chegam para o BIG-IP que por sua vez encaminha para o servidor balanceado. O servidor balanceado processa as solicitações e devolve as respostas. As respostas então são encaminhadas pelo BIG-IP para o cliente original. O BIG-IP é uma espécie de intermediário em todas as transações.
Por fim, quando o cliente ou o servidor se derem por satisfeitos e terminarem a conexão, o BIG-IP vê esse término das conexões e finaliza todo o fluxo.
Interessante, não? E você, o que achou? O que você gostaria que fosse abordado nos próximos artigos? Comente com sugestões e não deixe de seguir o TechRebels e a mim aqui no Medium clicando no “follow” ali embaixo para saber mais sobre BIG-IPs e diversos outros assuntos!
/FIN=1
Sobre o autor
Rafael Bianco Nacif é analista de redes sênior. Graduado em Redes de Computadores, certificado F5 Solutions Expert Security e também Cisco CCNP DC e RS. Iniciou a carreira na área de TI como help-desk e hoje atua em projetos de DC de altíssima complexidade. linkedin.com/in/rafaelbn
