Exibir código-fonte para Data Center IPv6-only com SIIT-DC e Jool


=== Introdução ===

Esse breve artigo prático pretende demonstrar o uso do mecanismo SIIT-DC proposto na RFC 7755, desabilitando o IPv4 nas configurações dos serviços e aplicações de um Data Center, simplificando a gerência e a resolução de problemas na rede, sem deixar de atender os clientes externos que ainda estão em IPv4 e necessitam consumir os serviços oferecidos pelo seu portal Web, por exemplo, somente com IPv6 configurado. Será utilizado o software de código aberto [https://github.com/NICMx/Jool Jool], desenvolvido pela equipe de analistas, engenheiros e estudantes do [https://www.nicmexico.mx/ NIC México]. Este estudo faz parte de um trabalho realizado na [http://www.unicamp.br Universidade Estadual de Campinas] (UNICAMP) para promover o uso do IPv6-only na rede do Data Center.

Além disso esse artigo é um convite a todos a se prepararem para uma administração dos serviços providos num Data Center rumo ao uso de um único protocolo IP. Há anos, digo desde a década de 90, trabalhar somente com o IPv4 em uma rede é o que estávamos acostumados até o aparecimento da primeira proposta de IPv6 em 1998. Atualmente temos a necessidade de conviver com duas versões no modelo chamado pilha dupla (''dual-stack'') nessa fase de transição de versões IPv4 para IPv6 e esperamos que em breve ( uns 5 anos, será ??? ) seja concluído. Porém a modalidade ''dual-stack'' tem suas desvantagens e não devemos nos acostumar com ela ou evitar a adoção para o modelo de um único protocolo IP na rede, no caso o IPv6. Com ''dual-stack'' você terá que realizar tudo em dobro, uma dupla configuração de regras (ACLs), duplo gerenciamento e monitoramento, duas tabelas de roteamento, o que aumenta a atenção, erros de operações, além do trabalho duplicado diário. Acredito que podemos deixar nossa vida de administração de redes mais tranquila, essa é a proposta.
=== A ferramenta Jool ===

A ferramenta Jool, de código aberto, pode ser instalada em qualquer distribuição Linux atual. É uma ferramenta que possui uma comunidade ativa, atualizações e correções de problemas frequentes e é principalmente mantida pela equipe de desenvolvedores do NIC México. Tenho muito a agradecer a Jorge Cano e Alberto Leiva pelo suporte e aprendizado durante esses anos.

Além disso, é uma ferramenta estável, simples, fácil de usar, possui um bom desempenho e não exige muita CPU e Memória RAM. Outro detalhe que chama atenção é com relação aos logs de tradução gerado com detalhes, importante hoje em dia durante uma análise de incidentes de segurança. A documentação completa e detalhada pode ser acessada no site do [https://nicmx.github.io/Jool/en/index.html Jool].
=== O que é o SIIT-DC? ===

O uso da tradução SIIT (''Stateless IP/ICMP Translation Algorithm'') em ambiente de Data Center (DC) é uma maneira fácil de avançar com os projetos de transição para uma rede somente IPv6 e que não requer mudanças drásticas na infraestrutura ou alterações do núcleo (core) da rede, retirando simplesmente do ambiente ou "desligando" o protocolo IPv4 dos serviços e aplicativos. Clientes com IPv6 em suas máquinas não passam por essa tradução e acessam os serviços de um Data Center diretamente, restaurando a conexão fim a fim, no qual foi abandonada por anos, com o uso do NAT. Clientes que ainda estão em IPv4 passam por um mecanismo de tradução em um novo elemento adicionado na topologia da rede chamado Border Relay (BR). Podemos compreender melhor o funcionamento do SIIT-DC com a ilustração da Figura 1.

[[Arquivo:Topologia SIIT-DC.png|miniaturadaimagem|Figura 1 — Topologia SIIT-DC (Fonte: Site Jool)|centro|420x420px]]

Nesse artigo foi configurado em s6 de acordo com a Figura1, um servidor Apache Web de forma a demonstrar o funcionamento da tradução SIIT-DC realizada pelo BR. A mesma ideia deve ser aplicada nas configurações de outros serviços providos por um Data Center. 

As traduções dos prefixos ocorrem de forma bidirecionais pela ferramenta Jool seguindo a [https://datatracker.ietf.org/doc/html/rfc6052 RFC 6052]. Uma tabela de mapeamentos de endereços chamada EAMT (''Explicit Address Mapping Specification'') proposto na [https://datatracker.ietf.org/doc/html/rfc7757 RFC 7757] deverá ser criada no Border Relay sendo composta de prefixos IPv4 e IPv6 que informam como a tradução deverá ocorrer. Os endereços IPv4 não devem ser utilizados em nenhuma interface de rede, apenas devem ser informados na tabela de mapeamento e no DNS, com rotas até o BR. O endereço IPv4 de origem é mapeado 1:1 dentro de um prefixo IPv6 96-bit. Exemplo:

<pre>
# jool_siit eamt display
+---------------------------------------------+--------------------+
|                                 IPv6 Prefix |        IPv4 Prefix |
+---------------------------------------------+--------------------+
|                  2801:8a:c040:fca0::245/128 |    177.220.17.8/32 |
|                  2801:8a:c040:fca0::241/128 |    177.220.17.7/32 |
|                  2801:8a:c040:fca0::242/128 |    177.220.17.6/32 |
|                  2801:8a:c040:fca0::244/128 |    177.220.17.5/32 |
+---------------------------------------------+--------------------+
</pre>

A tradução realizada pelo mecanismo SIIT-DC não guarda nenhum estado associado as conexões (''stateless'') alcançando assim uma alta disponibilidade e desempenho. Com isso o Border Relay pode ser configurado em uma máquina virtual ou até num Raspberry Pi. Caso haja uma falha o tráfego pode ser direcionado para outro BR facilmente sem maiores impactos na rede. Há possibilidade de se trabalhar com vários BR de forma balanceada, o que é recomendado. Com relação a melhor localização de se instalar um BR na topologia da rede do Data Center, o ideal é que fique o mais próximo do caminho dos serviços IPv6, entre os Firewalls, IDS e balanceadores de carga.

Mas como fica a parte de rastreabilidade ou auditoria durante a tradução? O cliente e algumas ferramentas podem não perceber que o servidor destino tem somente um endereço IPv6 configurado em sua interface. Uma das mágicas que acontece durante a tradução é que o endereço IPv4 de origem não é perdido. Isso é ótimo para uma auditoria em logs de um servidor Web. Na Figura 2, temos o exemplo de uma parte do arquivo de access.log .

[[Arquivo:Figura 2 - Parte do arquivo de log do Apache Server..png|centro|miniaturadaimagem|829x829px|Figura 2 - Parte do arquivo de log do Apache Server]]

Podemos inclusive perceber nesse log de exemplo os IP de origens em IPv6 direto (destaque em vermelho) e os IPv4 que sofreram tradução (destaque em verde). Fazendo a conversão do IP 64:ff9b::175f:648d para decimal, podemos chegar ao IPv4 de origem 23.95.100.141 .

<pre>
Lembrete: É importante entender que como estaremos configurando apenas um endereço global IPv6 na interface de rede do servidor Web, ele conseguirá apenas acessar destinos com IPv6. Isso não é problema para o servidor atualmente, pois temos tanto os repositórios de atualizações Linux e Windows em IPv6, caso a atualização do Sistema Operacional seja necessário. O problema acontece quando o servidor tenta iniciar uma conexão com destinos IPv4. Dessa forma o servidor passa a ter um comportamento de cliente e não irá conseguir acessar diretamente os destinos em IPv4, sendo necessária uma combinação de técnicas NAT64/DNS64 + SIIT-DC. 
</pre>

=== Configurando o Border Relay ===

A distribuição Linux utilizada na máquina virtualizada é o Oracle Linux 8, Kernel 5.4.17, CPU 1 Core Intel Xeon, 2GB RAM, 1 interface de Rede Intel PRO/1000. Não abordaremos aqui a instalação e configuração do Oracle Linux 8 como também as configurações dos IPs nas interfaces de rede e o roteamento. O software Jool pode ser encontrado no site do Jool em sua última versão. O download pode ser feito tanto no formato tarballs como pelo repositório Github.

<pre>
# wget https://github.com/NICMx/Jool/releases/download/v4.1.8/jool-4.1.8.tar.gz

ou

# git clone https://github.com/NICMx/Jool.git
</pre>

A instalação dos módulos do Jool devem ser feitas através do suporte de módulo de kernel Dinâmico (DKMS), fazendo com que a cada nova versão do Kernel atualizado, todos os módulos DKMS são recompilados automaticamente. Após o download e a sua descompactação, executar o comando:

<pre>
# /sbin/dkms install jool-4.1.8/
</pre>

Os arquivos executáveis da aplicação Jool devem ser instaladas de forma separada aos do módulo do Kernel executando para isso a sequência de comandos:

<pre>
# cd jool-4.1.8/
# ./configure
# make
# make install
</pre>

O módulo do Jool deve ser carregado no kernel.

<pre>
# modprobe jool_siit
</pre>

Uma tabela de mapeamento de endereços chamada EAMT, como já citamos, descreve como diferentes endereços devem ser traduzidos. No Jool todos os registros são bidirecionais e para executarmos devemos informar o prefixo pool6 para tradução de endereços IPv4 para IPv6 a serem utilizados conforme o cenário proposto, executando os comandos:

<pre>
# sysctl -w net.ipv4.conf.all.forwarding=1
# sysctl -w net.ipv6.conf.all.forwarding=1
# 
# jool_siit instance add  --netfilter --pool6 64:ff9b::/96
# jool_siit eamt add 2801:8a:c040:fca0::241 177.220.17.7
# jool_siit eamt add 2801:8a:c040:fca0::242 177.220.17.6
# jool_siit eamt add 2801:8a:c040:fca0::244 177.220.17.5
# jool_siit eamt add 2801:8a:c040:fca0::245 177.220.17.8
</pre>

O Jool permite utilizar um arquivo de configuração no formato JSON (jool.conf) como uma maneira prática de guardar as configurações atuais podendo ser adicionados como um script de inicialização e a cada reboot iniciá-lo automaticamente.

<pre>
{

        "comment": "SIIT Configuracao",
        "instance": "default",
        "framework": "netfilter",

        "global": {

                "pool6": "64:ff9b::/96"
        },

        "eamt": [
                { "ipv6 prefix": "2801:8a:c040:fca0::244", "ipv4 prefix": "177.220.17.5" } ,
                { "ipv6 prefix": "2801:8a:c040:fca0::242", "ipv4 prefix": "177.220.17.6" } ,
                { "ipv6 prefix": "2801:8a:c040:fca0::241", "ipv4 prefix": "177.220.17.7" } ,
                { "ipv6 prefix": "2801:8a:c040:fca0::245", "ipv4 prefix": "177.220.17.8" }
        ]

}
</pre>

Para executar o arquivo de configuração jool.conf no formato JSON use o comando:

<pre>
# jool_siit file handle /etc/jool.conf
</pre>

Para facilitar a execução do Jool como serviço do systemd no Linux podemos criar o arquivo jool.service em /usr/lib/systemd/system e adicionar as linhas:

<pre>
[Unit]
Description=Jool Service
ConditionPathExists=/etc/jool.conf
After=network.target

[Service]
Type=forking
RemainAfterExit=yes
ExecStartPre=/sbin/modprobe jool_siit
ExecStart=/usr/local/bin/jool_siit file handle /etc/jool.conf
ExecStop=/usr/local/bin/jool_siit -f /etc/jool.conf instance remove

[Install]
WantedBy=multi-user.target
</pre>

=== Conclusão ===

Não temos como escapar, o IPv6 já está circulando na sua rede e pode ser que você não tenha percebido isso. Além disso, já está na hora de começarmos a pensar sobre a remoção do IPv4 da rede. Essa é a proposta e o desafio deste artigo simples e prático. Com o uso do mecanismo SIIT-DC, podemos finalmente avançar um pouco mais na transição para um mundo IPv6-only, reduzindo a quantidade de endereços IPv4 no Data Center, podendo ser remanejado para outras operações onde ainda tenham dispositivos legados ou quem sabe até devolvendo o bloco para o seu RIR.

Podemos citar como vantagens:
* Não se perde o endereço IPv4 de origem (auditoria). Controle de acesso e firewalls sem alterações.
* Alto desempenho (kernel). Atrasos desprezíveis no Border Relay.
* Simplicidade no gerenciamento e configuração do Data Center.
* Evita a complexidade no uso de duas versões do protocolo IP em Aplicações e Servidores.
* Tendência mundial (Facebook, AWS, Google, Microsoft, …)

E quando o IPv4 morrer de vez  (R.I.P.) e não for mais necessário, apenas remova o registro IN A no DNS e desligue o seu SIIT-DC (Border Relay). Bye bye IPv4.

Espero com esse tutorial ter auxiliado e incentivado a adoção do IPv6-only nos serviços de um Data Center, com ajuda da ferramenta Jool como uma ferramenta simples de uso na prática. 

Qualquer dúvida, sugestões, comentários, estou a disposição. [https://www.linkedin.com/in/henri-alves-godoy/ Linkedin]

Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Henri.godoy Henri A. Godoy]

=== Referências ===
* [https://nicmx.github.io/Jool/en/documentation.html Documentação Completa do Jool | NIC.MX]
* [https://www.lacnic.net/2467/1/lacnic/ Implementando SIIT/NAT64 usando Jool | Webinar LACNIC]
* [https://prensa.lacnic.net/news/ipv6/jool-una-herramienta-que-facilita-el-camino-a-ipv6 Jool, una herramienta que facilita el camino a IPv6 | LACNIC News - Abril 2019]
* [https://www.lacnic.net/5576/64/evento/operacion-de-redes-ipv6 Tutorial de Operação de Redes IPv6 | LACNIC 36 | Uesley Correa]
* [https://datatracker.ietf.org/doc/html/rfc7755 RFC 7755 | SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments]
* [https://datatracker.ietf.org/doc/html/rfc6052 RFC 6052 | IPv6 Addressing of IPv4/IPv6 Translators]

==== Internet-Drafts sobre o assunto ====
* [https://tools.ietf.org/html/draft-ietf-v6ops-transition-comparison-04 Pros and Cons of IPv6 Transition Technologies for IPv4aaS]
* [https://tools.ietf.org/html/draft-ietf-v6ops-ipv6-deployment-10 IPv6 Deployment Status]
* [https://tools.ietf.org/html/draft-palet-v6ops-464xlat-opt-cdn-caches-04 464XLAT Optimization]
* [https://tools.ietf.org/html/draft-palet-v6ops-ipv6-only-05 IPv6-only Terminology Definition]
* [https://tools.ietf.org/html/draft-ietf-6man-mtu-option-15 IPv6 Minimum Path MTU Hop-by-Hop Option]
* [https://tools.ietf.org/html/draft-ietf-6man-ipv6only-flag-05 IPv6 Router Advertisement IPv6-Only Flag]
* [https://datatracker.ietf.org/doc/html/draft-lmhp-v6ops-transition-comparison-06 Pros and Cons of IPv6 Transition Technologies for IPv4aaS]

[[Categoria:Infraestrutura]]
[[Categoria:IPv6]]