CGNAT com F5 BIG-IP

Olá amigos do BPF!

Meu nome é Rafael e falaremos sobre as soluções CGNAT que o fabricante F5 pode oferecer!

Antes de mais nada, quero deixar claro que as opiniões expressadas nesse artigo são minhas e não refletem as opiniões de meu empregador e nem da F5.

Dito isto, vamos começar respondendo a pergunta: Quem é o Rafael?

Trabalho com a plataforma BIG-IP da F5 desde 2017. Possuo algumas certificações do fabricante e já entreguei alguns projetos em cima da plataforma, incluindo 7 sites CGNAT distribuídos pelo Brasil. Sou um dos colaboradores da publicação TechRebels e escrevo por lá mensalmente. Você pode me achar no Linkedin também!

Agora, sem mais delongas...

Introdução

A F5 hoje oferece através de sua plataforma BIG-IP diversas soluções, dentre elas o CGNAT. Você consegue utilizar o CGNAT em seu módulo puro ou pode associar o CGNAT ao módulo de firewall camada 4 chamado AFM. No modo CGNAT puro, somente as funcionalidades de CGNAT estão disponíveis. Já no módulo AFM, além das funcionalidades do CGNAT, temos também todas as funcionalidades de um firewall camada 4 (regras e ACLs tradicionais) e também proteções contra DoS mais sofisticadas.

Além dos módulos, a F5 provê 3 tipos de plataforma: Chassi Viprion, appliance e virtual edition.

Todas as 3 plataformas podem realizar a entrega do serviço CGNAT. O chassi certamente é o mais parrudo em termos de desempenho, provendo arquitetura modular, fontes redundantes e tamanhos variados (de 2 até 8 blades). Os appliances por sua vez possuem tamanho reduzido (2RU) e têm uma variedade de configurações. Por fim, o virtual-edition é uma VM, que roda nas principais hypervisores de mercado, possuindo inclusive VMs de alto desempenho, com throughputs que chegam à 100Gbps.

Todas as plataformas possuem o mesmo look-n-feel via linha de comando ou interface gráfica (browser sem java!), então a operação é sempre parecida.

TMOS - Apresentação

O TMOS ou Traffic Management Operating System é o sistema operacional do BIG-IP. Pense nele como o IOS do mundo Cisco. O TMOS roda em cima de um kernel Linux altamente customizado para suportar muitas conexões simultâneas. Muitas mesmo! Olhem essa imagem:

Esse gráfico foi retirado de um ambiente de produção rodando em uma VM high performance com o BIG-IP CGNAT. Todas as 133mil conexões estão sendo sustentadas pela VM do BIG-IP que apresenta uma média de CPU abaixo de 40%.

Digo isso pois sustentar conexões simultâneas é o arroz com feijão do BIG-IP. São anos e anos otimizando código para fazer isso muito bem.

Além disso, como falado anterirmente, o BIG-IP é construído em cima de um kernel Linux, então toda a robustez que o Linux oferece também é aproveitada e, adicionalmente, todos os comandos úteis do Linux estão ao seu dispor.

CGNAT - Características

Para o módulo CGNAT do BIG-IP, você tem ao seu dispor os modos de operação:

Nat determinístico - Em que os IPs nateados são pré-determinados
Nat dinâmico com alocação de blocos de portas, ou PBA - Em que é definido um bloco de portas que o cliente irá utilizar. Esses blocos, depois de um timeout, são reaproveitados por outro cliente.

Vamos focar no modo PBA que é o mais atrativo para a maioria dos provedores por ter um grande reaproveitamento de IPs quentes.

CGNAT - Porta Block Allocatin (PBA)

No modo PBA, o BIG-IP em sua versão mais atual (15.1) conta com diversas funcionalidades, dentre elas cito:

Múltiplos prefixos de saída, com máscaras diferentes
Range de portas de saída personalizável
Timeout customizável dos blocos
Tamanho do bloco reservado para o cliente personalizável
Limite ajustável de quantos blocos um único cliente pode receber
Refresh de logs ajustável
Suporte aos protocolos de roteamento de mercado, como BGP e OSPF, onde é possível injetar os IPs quentes de saída pelo próprio BIG-IP

CGNAT - Outras características

O BIG-IP possui além do CGNAT outras características interessantes:

Segregação do ambiente com o uso de route-domains (equivalente às VRFs do mundo Cisco)
Suporte ao IPv6 (seja para NAT ou não)
Segregação de controle de acesso ao gerenciamento da caixa, com partições administrativas
Operação em cluster, com alta disponibilidade do ambiente no modo n+1 ou ativo/standby, provendo failover statefull da conexão do cliente. Isso em qualquer plataforma: chassi, appliance e virtual-edition
Gerenciamento centralizado de ambientes com múltiplos dispositivos utilizando o produto BIG-IQ

CGNAT - Topologia de Exemplo

A seguir temos uma topologia de exemplo com um ambiente sendo atendido por um par de virtual-editions, rodando em cluster ativo/standby. Os clientes foram divididos em dois ambientes. separados por route-domains (VRFs), impossibilitando a comunicação de um cliente diretamente com outro. Ao receber a conexão do cliente, o BIG-IP reserva um bloco PBA, envia a mensagem de syslog do bloco reservado para fins de auditoria e roteia o cliente para a internet. Ao mesmo tempo, conexões originadas da internet com destino aos cliente externos são dropadas pelo BIG-IP protegendo o cliente.

Nesse ambiente, o client1 (172.16.10.100) tem R1-INT como seu default gateway. R1-INT por sua vez tem uma rota default para a VRF em questão, apontando para o IP de float dos BIG-IP (o IP de float é uma espécie de VRRP entre os BIG-IPs que participam do cluster). R1-INT então encaminha o pacote do client1 (que ainda é RFC1918) para o BIG-IP ativo.

O BIG-IP ativo aceita o tráfego e aplica as regras de CGNAT definidas (tamanho do bloco, IP de saída e etc). Através do BGP entre BIG-IPs e R1-EXT, os BIG-IPs anunciam a rota de retorno dos blocos CGNAT e também recebem uma rota default para a internet.

O pacote do client1, agora com IP quente 100.100.100.0/23 cujo destino é o servidor 8.8.8.8 segue as rotas definidas no backbone. O servidor 8.8.8.8 responde para o IP 100.100.100.0/23 do client1. O anúncio via BGP dos BIG-IPs puxa o retorno do tráfego até o BIG-IP ativo. O pacote ao bater no BIG-IP, por sua vez, dá match na tabela de conexão do BIG-IP, que desfaz o NAT para o IP de origem RFC1918 de client1 e devolve para o R1-INT. R1-INT, por sua vez, segue sua tabela de roteamento até client1.

Em ambientes clusterizados, podemos opcionalmente realizar o espelhamento dessa tabela de conexão entre os equipamentos envolvidos, para que em caso de queda de caixa, o cliente com conexão estabelecida para a internet não sofra de desconexão (failover statefull).