Dissecando Persistência no BIG-IP — Parte 2

Rafael Bianco Nacif
TechRebels
Published in
7 min readMay 28, 2020

Álcool gel… Syn, syn-ack, ack!!! (pa dum tss)…

Fala pessoal!! Seguimos com a nossa série sobre persistência de tráfegos no BIG-IP aqui no TechRebels! Você pode encontrar todos os meus posts publicados 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 artigo anterior, iniciamos a conversa sobre persistências falando sobre a persistência por source-address. Vimos que, para tal, o BIG-IP mantém uma tabela interna com o IP de origem da conexão e, quando aquele IP retorna, o balanceador entrega o tráfego preferencialmente para o mesmo pool-member que está anotado na tabela.

Mas, e se por algum motivo as conexões dos clientes vierem através de um proxy de internet, ou seja, chegarem sempre com o mesmo IP? Ou ainda, e se o IP do cliente mudar, como é o caso de praticamente todas as conexões à internet residenciais? Tudo iria por água abaixo. E é por isso que hoje vamos conversar sobre a persistência por cookies.

Então, como sempre, prepare seu café ou coca-cola geladinha e vamos nessa!

A persistência por cookies não é algo novo. Os cookies em si começaram a ser imaginados em 1994 e, logo nos anos seguintes, começaram a ser utilizados por diversos sites de e-commerce. Hoje, sem os cookies, navegar para os seus sites favoritos seria totalmente diferente, pois muitas informações sobre suas preferências de compras e personalizações são baseados nos cookies que o seu browser armazena.

Para ficarmos na mesma página, um cookie é uma extensão/opção do protocolo HTTP. É um header que existe dentro das mensagens do protocolo HTTP em si. Quando você acessa um site novo, que nunca navegou, o servidor web, ao devolver o conteúdo, devolve também uma série de cookies. Esses cookies são armazenados pelo seu browser por tempo indeterminado (ou determinado) e, quando você retorna ao site novamente, o seu browser, ao solicitar o conteúdo, entrega junto os cookies que ele tem salvos para aquele site. Com isso, o webserver que te atendeu pode devolver para você conteúdos personalizados, pois ele sabe quem é você pelo cookie que o seu browser informou.

Eu gosto de pensar nos cookies como uma “carteirinha” de associação. O webserver coitado não consegue lembrar quem é quem nesse mundão da internet, então, você, ao falar com ele, apresenta sua “carteirinha” e o webserver consegue saber quem é você e te apresentar conteúdos mais relevantes.

Pois bem, e como a persistência por cookies do BIG-IP funciona?

Obviamente estamos falando de tráfego HTTP. O BIG-IP por estar no meio do fluxo entre o cliente e o servidor web, adiciona um cookie no cabeçalho HTTP. Dentro desse cookie, o BIG-IP armazena qual foi o pool-member que atendeu aquele cliente. Quando esse cliente retorna em um outro momento, o BIG-IP verifica o cookie que ele inseriu e consulta para qual pool-member ele encaminhou e tenta honrar aquela mesma decisão de balanceamento. E voilà- temos uma persistência por cookies.

O que é importante sabermos sobre a persistência por cookies:

  1. O virtual-server precisa ter um profile HTTP anexado, pois o BIG-IP precisa ir até a camada da aplicação (no caso HTTP) para ler o cookie e injetá-lo quando necessário.
  2. Se o cliente trocar o browser ou utilizar uma janela anônima, um novo cookie será inserido e uma nova decisão de balanceamento acontecerá.
  3. Por padrão, e com um pouco de esforço, você pode decodificar a informação do cookie e saber exatamente o IP e porta do pool-member que atendeu aquela conexão.
  4. O BIG-IP, por padrão, utiliza persistência por cookie de sessão, ou seja, ao fechar o browser, o cookie é destruído. Se você quiser que o cookie fique salvo por mais tempo, deverá habilitar um “timeout” para o cookie.

Então, mãos à massa. A seguir a topologia do nosso lab.

Nosso lab permanece igual e acho que a essa altura do campeonato vocês já se conhecem bem, não é verdade? Temos o VIP 10.122.18.200 escutando na porta TCP-80. O virtual-server aponta para o pool_www, que possui os servidores green e red. O BIG-IP chega nesses dois servidores através de seu SNAT Auto-Map, ou seja, IP 10.122.18.10. O cliente da conexão chega via RT-1. Por conta da necessidade nº1 da lista lá em cima e também para ficar mais fácil de ver isso acontecendo, troquei o tipo do virtual-server para “standard”.

O passo a passo seria mais ou menos assim:

  1. O cliente executa o 3-way-handshake com o BIG-IP.
  2. O cliente envia o GET HTTP para o BIG-IP.
  3. O BIG-IP analisa o GET HTTP. Como temos um VS com persistência por cookie, o BIG-IP verifica se no GET do cliente existe um cookie com alguma decisão de balanceamento anterior.
  4. Se houver um cookie, o BIG-IP lê a informação armazenada nele e tenta enviar para o pool-member (tenta, pois o pool-member pode estar down). Caso o pool-member esteja fora do ar, o BIG-IP executa uma nova decisão de balanceamento e atualiza essa informação no cookie.
  5. Se não houver um cookie anterior do BIG-IP, uma decisão de balanceamento é tomada de acordo com o algoritmo de balanceamento configurado no pool que atende esse VS.
  6. Assim que o BIG-IP recebe a resposta do pool-member, ele injeta o cookie de persistência com a informação de qual pool-member atendeu a solicitação e encaminha a resposta para o cliente.

Agora, vamos dar uma olhada nas opções mais comuns em um profile de persistência do tipo cookie:

  1. O nome do objeto dentro do BIG-IP.
  2. O tipo de persistência que ele é, no caso, cookie.
  3. Quem é o profile pai dele, ou seja, o profile do qual as diversas opções serão herdadas.
  4. Cookie Name → Você pode especificar o nome que quiser. Se nenhum for mencionado, o BIG-IP utiliza “BIGipServer”.
  5. Default Cookie Encrypt Pool-Name → Se você usar o cookie name padrão, ou seja, não especificar um nome, além do BIG-IP utilizar o nome “BIGipServer”, ele adiciona ao nome do cookie o nome do pool que atendeu a solicitação, ou seja, no nosso caso ficaria “BIGipServerpool_www”. Ao selecionar essa opção ,o BIG-IP criptografa a parte do pool name evitando vazamento de informação.
  6. Expiration → Por padrão, o cookie é do tipo sessão, ou seja, se o browser for fechado, o cookie é destruído. Desmarcando essa opção, o BIG-IP te dá a alternativa de especificar o tempo que o cookie permanecerá armazenado no browser do cliente. Atente que o BIG-IP atualiza esse timestamp em cada resposta que ele envia para o cliente.
  7. Cookie Encryption Use Policy → Determina se você deseja que o BIG-IP cifre o conteúdo do cookie, de forma que não seja possível descriptografar de forma simples o conteúdo dele.
  8. Encryption Passphrase → Qual chave/string será utilizada para cifrar o conteúdo do cookie.

E agora, como sempre, vamos ao vídeo com a demonstração e também análise da captura de pacotes.

Em resumo, a persistência por cookies é amplamente utilizada em ambientes na internet. Sem ela, a internet seria — arrisco dizer — muito diferente do que conhecemos hoje. Vimos também que para o BIG-IP poder utilizar a persistência por cookies precisamos que ele “leia” até a camada de aplicação, ou seja, precisamos de um profile HTTP habilitado no VS. E por fim, entendemos que ao utilizarmos a persistência por cookies, dependemos que o usuário da aplicação utilize sempre o mesmo browser ou que não utilize os recursos de janelas anônimas dos mesmos.

O que você achou da persistência por cookies? Ela já resolveu algum problema de alguma aplicação sua? Me conta aí nos comentários! No próximo artigo iremos explorar a persistência universal, a mais casca grossa de todas!

Ficou com alguma dúvida? Pode perguntar! Os comentários e perguntas 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 2xF5 Solutions Expert (Cloud/Sec), 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