Servidor Logs CGNAT

Introdução

Com a escassez do recurso IPv4 no mundo, a resistência de muitas organizações que ainda não tem seus sistemas e conteúdos disponibilizados em IPv6, de muitos Provedores de Internet que ainda não entregam IPv6 nos seus clientes, tudo isso torna lenta a mudança de uma Internet antiga e legada, para uma Internet melhor e mais moderna. Mas por que toquei nesse assunto? Porque enquanto usarmos o IPv4 nessa situação, todos nós Operadoras ISP teremos que utilizar um recurso para continuarmos crescendo chamado de CGNAT (Carrier Grade Network Address Translation), que não trás nenhuma qualidade para nossos assinantes ou benefício para o crescimento da Internet. Para mim, CGNAT ou também conhecido como CGN, é uma muleta para a Internet continuar funcionando enquanto o IPv6 não se prevalece no mundo.

O CGNAT tem o objetivo principal de compartilhar IPv4 público e existem diversas soluções comerciais e não comerciais no mercado, mas que não vem ao caso aqui. O que importa para o nosso artigo, é a maneira como ele é implementado e que precisaremos armazenar os logs de conexão por pelo menos 1 ano, segundo o Marco Civil da Internet. Sempre que precisarmos identificar um cliente para uma Quebra de Sigilo Tecnológico, faremos uso dos logs armazenados.

Nesse artigo trataremos da montagem de um servidor de logs de CGNAT utilizando um Debian GNU/Linux e programas livres, de forma organizada para facilitar as consultas e abordaremos o recebimento de logs tanto via syslog quanto via netflow.

Tipos de implementação do CGNAT

Determinístico: onde usamos uma tabela de associação estática entre os IPv4 públicos, suas portas lógicas de origem e os IPs privados usados pelos clientes. Podemos encontrar por exemplo configurações de compartilhamento de 1/16, 1/32, etc, onde por exemplo: 1/32 seria compartilhar 1 IPv4 público com 32 clientes. Essa relação está associada à quantidade de portas lógicas alocadas para o cliente e que no caso de 1/32 seriam algo em torno de 2000 portas para cada cliente. Existe uma ideia errada de que se estamos usando Determinístico, então não precisamos armazenar logs. Em certo ponto está certo porque existe uma associação estática que não deveria mudar, mas se em algum momento você precisar reorganizar sua tabela de associação estática, você precisará ter um controle de quando isso foi alterado, de como era a tabela antes e de como ficou, porque senão você acabará identificando o cliente errado. Minha humilde sugestão: sempre armazene os logs, não importando se é Determinístico ou não.

Bulk Port Allocation: