[GTER] Soluções para a escassez de IPs públicos

[Felipe Trevisan]

Vejam só o problema de um cliente, relacionado a escassez do IPv4, mas
diferente do que se discutiu até aqui.

Ele tem uma aplicação que faz consulta a bancos para pegar atualização dos
extratos dos clientes. Ou seja, com milhões de usuários de seu aplicativo,
ele faz milhares de consultas aos bancos (Bradesco, Itau, Santander, etc.),
a toda hora, todos os dias.
Por medida de segurança, o banco bloqueia as consultas de um determinado IP
caso muitas consultas repetidas sejam feitas, que é justamente o caso da
aplicação do cliente.

O desafio dele é conseguir milhares de IPs nacionais (100 Classes "C") para
serem usados rotativamente. E para piorar não podem ser sequenciais. Não
adianta receber um /16 porque com o uso constante o banco pode bloquear
todo o /16.
Quando o banco bloqueia, é por no máximo 90 dias.

1 - Porque não faz uma conexão direta aos bancos? Bancos não aceitam.
Processo lento, anos para homologar
2 - IPV6? Aparentemente seria a solução. Bancos não tem previsão de quando
vão implementar segundo eles.
3- VPN? Nao pode ser feita. Questão de segurança também.


Solução encontrada até agora.

Proxy. Ele consegue alugar blocos de IP, mas somente IPs dos EUA e
Alemanha. Não há ninguém fazendo isso aqui. Ele joga esses IPs em um proxy,
que apresenta um IP para cada consulta,  e vai rotacionando esses IPs
baseado no banco consultado, numero de consultas, etc.

Problema - Bancos são criteriosos com consultas vindo de IPs de fora do
Brasil, e tendem a bloquear quando identificam ainda menos consultas
repetidas.


Solução aparentemente ideal.

Alugar blocos /24 aleatórios.

Precisaria encontrar ASNs com pelo menos um /24 disponível para contratos
de locação de curto prazo (90 dias). O ASN dono deixa de anunciar aquele
bloco. O ASN que hospeda a aplicação passa a anunciar o bloco, e permanece
anunciando pelo prazo combinado. Este prazo de locação pode ser ser
renovado algumas vezes, mas ele fatalmente vai expirar em um determinado
momento e o bloco será devolvido, podendo ser novamente locado no futuro.


Alguma outra sugestão de como resolver?


Abs,













2016-04-29 22:17 GMT-03:00 Raimundo Santos <raitech at gmail.com>:

> 2016-04-29 15:54 GMT-03:00 Márcio Elias Hahn do Nascimento <
> marcio at sulonline.net>:
>
> > Tendo esse
> > mapeamento, a ideia é quando requisitado, e de posse do IP de origem,
> > porta de origem, data e hora. De acordo com a porta de origem
> > identificar o IP Privado que a utiliza atras do IP público informado,
> > então com esse IP privado, procurar nos logs de accounting do radius o
> > usuário utilizando esse IP na data e hora especificados?
> >
> > Esse seria o
> > procedimento para identificar um usuário atras do CGNAT?
> >
>
> Aqui pra mim também a coisa é nova e NAT comum de pequeno porte tem
> resolvido o caso.
>
> Mas a ideia é que você consiga guardar informações temporais, ou seja,
> guardar direitinho qual cliente usou qual IP privativo em qual horário de
> tal forma que você consiga, através desse encadeamento de mapeamentos,
> associar a porta e o endereço IP de origem que o outro lado (justiça, outro
> provedor, provedor de conteúdo, etc...) lhe mostrar com o cliente que fez
> essa conexão.
>
> É por isso que dar portas fixas de um IP público em específico pra um IP
> privativo em específico é uma solução: o mapeamento é estático, no fim das
> contas, mesmo que a distribuição de endereços dentro da sua rede não seja -
> e é por isso que é muito importante ter a informação de quem usou e quando
> usou um endereço privativo.
>
> Você provavelmente nem precisa saber qual porta o privativo usou, só
> precisa mapear o púbico e sua porta até o cliente. (Principalmente com
> cliente doméstico, que raramente vai fazer log de qual processo usou qual
> porta naquele IP, naquele momento.)
>
> []s
> Raimundo Santos
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>