[GTER] CGNAT / Solucao para Log de tabela de estados de NAT

[Paulo Coimbra]

Interessante esse approach, Rubens, inclusive a parte de grupo de usuários
por range de ip valido ja faço isso em alguns casos. So nao faço ainda esse
controle por range de portas.

Quanto a obter mais blocos de IPs, pelo menos no nosso cenário aqui, onde
vendemos link para pequenos provedores (até 1000 clientes)  é meio
complicado pelo seguinte: o nosso cliente muitas vezes não tem know-how
técnico para obter um AS + IPv4 e mantê-lo. E se conseguirmos mais outro
prefixo (sim, temos 2 x /21 nao-contiguo) quando falamos de custos para o
cliente às vezes o cara assusta um pouco.

Entao a solucao que encontramos a momento foi: delegar o /30 da VLAN e o
bloco alocado (por exemplo /29, /28, /27, whatever! ) ao cliente e ele se
vire caso venha alguma ordem judicial.

Mas voltando ao caso do provedor, se apresentasse essa solução de log da
tabela de estados do NAT de repente seria uma saída pra eles(pelo menos por
enquanto).

Nos casos onde atendemos cliente final entregamos IPv4 válido por PPPoE e
estamos em implantação/estudo de  dual-stack (v4 e v6) mas somente v6 acho
inviável ainda..

Mas de qq forma obrigado a todos pelas sugestões e dicas, como sempre muito
úteis!

E a luta continua companheiros!!!

sds,

Paulo Coimbra

Em 28 de outubro de 2013 17:38, Rubens Kuhl <rubensk at gmail.com> escreveu:

> 2013/10/28 Paulo Coimbra <coimbra.root at gmail.com>
> >
> > Bom dia,
> >
> > Com o esgotamento de IPv4 e a baixa penetração do IPv6, qual seria uma
> > solucao rápida para "accounting" da tabela de estados de NAT, haja visto
> > que atualmente temos um /20 que é insuficiente para atendermos 100% dos
> > nossos clientes com IPv4 válido?
>
>
> 1) Peça mais IPs. Ainda há IPs disponíveis.
> 2) A solução mais simples é fazer mapeamento quasi-stateless. Funciona
> assim:
> -  Pegue cada grupo de 64 usuários e atribua a um IP específico de NAT.
> Todos esses 64 sairão por aquele IP.
> - Crie um range de portas para cada usuário. Por exemplo, usuários de 0 a
> 63, o usuário 0 tem porta origem de 0 a 1023, o usuário 1 de 1024 a 2047 e
> assim por diante.
>
> Isso em Linux iptables fica assim:
>
> iptables -t nat -A POSTROUTING -s 10.0.0.1 -j SNAT --to-source
> 200.200.200.1:0-1023
> iptables -t nat -A POSTROUTING -s 10.0.0.2 -j SNAT --to-source
> 200.200.200.1:1024-2047
>
> Isso fica chato de gerar por que é uma regra para cada cliente, mas coisas
> como o Template Toolkit (http://www.template-toolkit.org) podem ajudar
> nisso.
>
> Assim, toda vez que você receber uma denúncia dizendo IP origem tal e porta
> origem tal, você já vai saber quem é sem precisar consultar log algum.
>
> Infelizmente, nem todo pedido judicial vem com porta origem... mas esse é
> um hábito que o CGNAT terá que criar nos usuários de Internet, porque fora
> a porta origem, todo o resto caracterizaria observação do tráfego do
> usuário. Dependendo do perito ele poderia chamar isso de interceptação
> telemática e portanto crime... e independente de interpretação, é algo que
> vai estar proibido daqui a alguns dias com a aprovação do Marco Civil.
>
>
> Rubens
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



-- 
br,

Paulo Coimbra