Postado originalmente por
andrecarlim
Então, vou tentar mudar meu tom para algo mais didático, imaginemos uma estrutura onde o pequeno provedor receba um bloco de /30 para poder usar seu uplink com a operadora de trânsito, aqui sim, OPERADORA. Geralmente o que eu vejo por aí é que tem um NAT "apontado" para tudo que sair pela porta do Uplink, digamos, apenas a caráter didático que esse bloco do Uplink seja o 200.200.200.0/30, e o IPv4 do teu lado (pequeno PROVEDOR de internet) é o 200.200.200.2, e o provedor tem um servidor pppoe/hotspot distribuindo IPv4 de um POOL que compreende os IPs 192.168.0.1 até o 192.168.0.254, quando 200 clientes estiverem conectados usando esse concentrador pppoe/hotspot, nessa configuração, DO PONTO DE VISTA DA INTERNET, todos os 200 clientes são o mesmo IPv4, o 200.200.200.2, isso porque temos o NAT (Network Address Translation) trocando o IPv4 de origem em todos os pacotes que "saem" pela interface Uplink, isso é possível porque o "firewall" é statefull e tem uma técnica chamada de
conntrack, que permite manter uma tabela de relacionamento e distribuição entre as portas do IPv4 Público e os IPv4 privados, não roteáveis na Internet. OK? Entendido essa parte? Sem dúvidas? Vamos adiante!
Mas André o que é conntrack?
aqui ó...
A ideia do CG-NAT é basicamente a mesma, porém mantendo o "firewall" mais parecido com o modo stateless, ainda teremos o NAT e a conntrack, só que ao invés do mecanismo de NAT cuidar do relacionamento e distribuição das portas, nós é que configuraremos isso, para que o mesmo IPv4 privado e não roteável na internet, use sempre o mesmo range de portas para o IPv4 Público e roteável na internet. Só isso!
Mas André como faz isso? Nem vou falar, google é seu amigo nessas horas!
E porque toda essa explicação? O povo pensa que é tudo monitorado, ainda mais depois do escândalo revelado pelo Snowden sobre a NSA, mas e que isso importa na minha internet? NADA!
O que realmente importa é se alguém tirar fotos de uma criança sem roupa e enviar para algum site adulto, aí sim tem alguma importância. E como funciona isso, primeiro de tudo alguém te que ver a foto da criança e fazer uma denúncia, feito isso, a policia vai investigar, provavelmente a policial federal (eu acho, afinal sempre são eles que estão por dentro disso), logo após esse passo, vão solicitar a um Juiz que ele emita uma autorização/ordem judicial para intimar o site que recebeu a foto, e que esse site explique como aquilo foi parar lá. Se o administrador do site foi inteligente ele tem um formulário que tem um login e senha, e cada cada acesso cria um log associando o login/senha/conteúdo enviado/ip de origem/porta de origem, de posse desses dados a PF busca no registro.br (whois), por exemplo, e vê quem é o responsável pelo nosso IPv4 em questão, o 200.200.200.2, se a operadora não delegou ele, eles vão chegar até a operadora e pedir esclarecimentos sobre esse incidente, o que a operadora faz é um laudo informando que este IPv4 esta sendo usado pelo pequeno provedor e que não tem responsabilidade sobre o que acontece com este IP/Bloco, muito bem, agora a PF vai chegar no pequeno provedor que, salvo raros casos, nem tem SCM, e pedir esclarecimentos sobre esse incidente, e agora André? Bom temos duas supostas situações:
1) Se o pequeno provedor possui o primeiro modelo de configuração, aquele que usa um NAT para tudo que sai pela porta de Uplink, temos um problema bem grande, jamais, mesmo com muito esforço, o cliente que enviou as fotos será identificado, porque nesse modo "todo mundo usa todas as portas do IPv4 público", ou seja, não existe relacionamento direto entre IPv4 Público/Porta de origem/IPv4 Privado!
2) O pequeno provedor, por sorte e responsabilidade, tinha o CG-NAT implementado, então ele pode gentilmente informar a situação a PF e pedir que o Juiz emita um novo mandato/ordem judicial que autorize/obrigue o site lá do outro lado informar a porta de origem que foi usada para enviar (upload) das fotos, e com esse dados, poderá facilmente olhar na sua tabelinha de divisão das portas, quem, naquele dado momento, estava usando aquele range de portas, ou aquela porta de origem especifica e informar a PF que a responsabilidade era, de fato, daquele cliente! Se isso vai de fato surtir efeito, pouco se sabe, mas assim, evitamos uma boa parte de problemas, ainda tem outros problema que o NAT trás pra dentro da rede, problemas relacionados a VoIP, VPN IPsec e afins.
Sobre o comentário que quem informou nosso amigo lá que era só fazer um "ajustezinho" no mk-auth, entendamos o seguinte meus amigos, radius é uma ferramenta técnica, nada tem haver com planos de acesso, retorno de boletos e afins, o que temos por ai é uma monte de "sistemazinho" que implementa um radius (geralmente o freeradius), juntamente a um banco de dados (geralmente MySQL), e o que é feito é alguns scripts aqui e ali, algumas triggers no banco e etc, que manipulam o radius para criar essas ideias mirabolantes de que é um sistema todo que faz isso, e não é! Radius é algo muito antigo e que ficou "mais" popular nos ultimos tempos, se esses sistemas que tem por ai, os seus desenvolvedores, estudassem a fundo o radius a gente teria uns 90% a menos de problemas com isso nos provedores, eu mantenho um freeradius juntamente ao MySQL a mais de 8 anos para os clientes que atendo e não sofro com esses problema que vejo por aqui, sobre o radius, existe uma função que já vem pronta no freeradius, basta ativar, que é o RAD ACCOUNTING, que armazena, seja em arquivo, seja em banco de dados, algumas informações de cada conexão que é iniciada/finalizada. Esse rad acounting armazena o tal de framed-ip-address, que é o ip de conexão do cliente, só isso, nada adianta armazenar essa informação se você não vai conseguir identificar quem de fato mandou aquelas "fótinhas"!
Ficou claro? Alguma dúvida?