Topologias Clássicas: One-Arm

Syn, syn-ack, ack…

Fala pessoal!! Sejam bem-vindos à mais um artigo de F5 BIG-IP aqui no TechRebels! Você pode encontrar todos os meus posts publicados por aqui 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.

Na série passada, tratamos sobre o básico das iRules, lógica “if” e “else” e, por fim, falamos das famosas e polêmicas variáveis! Nesse artigo rápido iremos conversar sobre design, mais especificamente as topologias clássicas!

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

Pra começar com o pé direito, atentem para o título do artigo — topologias lógicas! Isso mesmo. Não importa quantas conexões físicas o seu BIG-IP tem para os outros equipamentos. Vamos analisar aqui o caminho lógico dos pacotes, OK?

Dito isso, vamos dar uma de saci pererê, pular novamente com o pé direito e falar logo de cara que não tem uma topologia “melhor” que a outra. Temos apenas a topologia que melhor atende ao seu ambiente e a necessidades das suas aplicações.

Muito bem, agora vamos ao que interessa! Começando pela one-arm, ou em tradução livre, um braço. A ideia da topologia one-arm, é que o BIG-IP só possui um enlace L3 com o restante da rede, ou seja, todo o tráfego que chega para o BIG-IP, sai pela mesma rede L3 que entrou. Vejam o diagrama a seguir.

Neste caso, a única comunicação que o BIG-IP tem com o restante do mundo é a rede 192.168.15.0/24. A grande questão dessa topologia é que, se você não tratar o retorno do tráfego, você irá se deparar com uma assimetria e, consequentemente, o fluxo não irá funcionar corretamente. E é por isso que, sempre que se fala de one-arm, automaticamente se pensa em SNAT! Não pescou o problema? Vamos ao passo-a-passo:

Primeiro sem SNAT!

1. Pacote SYN oriundo do cliente chega ao BIG-IP, com IP de destino do VIP, 192.168.15.21.
2. BIG-IP recebe e aceita o tráfego e por padrão realiza o DNAT para o endereço do pool-member, no caso 10.0.1.201. Nesse momento, o cabeçalho do pacote é: IP de origem cliente, IP de destino 10.0.1.201.
3. Esse pacote chega ao RT-1, que por sua vez encaminha — sem alterar nada — para o servidor WEB.
4. O servidor WEB recebe o pacote, processa e ao devolver a resposta, faz o que todo elemento de rede que fala TCP/IP faz, ou seja, responde com IP de origem 10.0.1.201 e IP de destino cliente.
5. Esse primeiro retorno, ao chegar no RT-1, apenas é roteado para o cliente diretamente, afinal, o IP de destino é o do cliente e não o do BIG-IP.
6. Finalmente, quando esse pacote chega ao cliente, ele não entende absolutamente nada! Isso acontece pois a conexão inicial era para o IP do VIP e não para o IP do servidor WEB. Consequentemente, o cliente dropa do pacote e a aplicação nunca funciona.

Agora a mesma aplicação, só que com SNAT!

1. Pacote SYN oriundo do cliente chega ao BIG-IP, com IP de destino do VIP, 192.168.15.21.
2. BIG-IP recebe e aceita o tráfego e por padrão realiza o DNAT para o endereço do pool-member, no caso 10.0.1.201. Além disso, foi utilizada a opção de SNAT auto-map, então, além de realizar o DNAT para o IP do pool-member, o BIG-IP também realiza o SNAT para o IP de sua interface de saída, ou seja, 192.168.15.11. Então, o pacote que saí do BIG-IP é: IP de origem 192.168.15.11 e IP de destino 10.0.1.201.
3. Esse pacote chega ao RT-1, que apenas o encaminha sem alterar nada.
4. O servidor WEB recebe o pacote, processa e ao devolver a resposta, devolve agora para o IP do BIG-IP, afinal, foi o IP que fez a conexão em primeiro lugar! Então o pacote de resposta que deixa o servidor WEB tem IP de origem 10.0.1.201 e IP de destino 192.168.15.11.
5. O RT-1 encaminha o pacote de volta para o BIG-IP, pois o IP de destino é o dele.
6. O BIG-IP recebe o pacote, consulta sua tabela de conexão e verifica que existe esse fluxo anotado e então desfaz o SNAT e o DNAT que havia feito no início e devolve o pacote com IP de origem 192.168.15.21 (VIP) e IP de destino do cliente.
7. O pacote sem nenhum NAT chega ao RT-1, que o encaminha para o cliente conforme sua tabela de roteamento.

Nessa topologia, utilizando SNAT, a aplicação funciona corretamente! Mas quais as vantagens e desvantagens? Vejamos… Como vantagem vejo uma topologia de roteamento simplificada, tudo entra e sai pela mesma rede! Como desvantagem, além de acabar utilizando o mesmo link físico múltiplas vezes para o mesmo fluxo, temos também o IP de origem das conexões para o servidor WEB sendo sempre o mesmo (no caso, o IP de SNAT auto-map do BIG-IP). Algumas aplicações perdem algumas funcionalidades com isso. No caso de aplicações HTTP é possível contornar com o uso do x-forward-for, mas nem todas as aplicações conseguem contornar essa questão.

Coloco essas vantagens e desvantagens meio que a contra-gosto, pois isso varia demais! Mas serve como um exercício de reflexão, vai.. =D

O que você acha da topologia one-arm? Tem alguma história pra contar? Compartilha aí com a galera! No próximo artigo iremos analisar a topologia two-arm, então fiquem ligados!

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 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