[GTER] Ideia para CGNAT determinístico com mix de redes /24s da RFC1918 (RouterOS)

[Douglas Fischer]

A dor que você está sentindo é inerente ao método determinístico!

Não existe solução "bonita" para ela...

Já vi umas gambiarras "automágicas" que remove e reinsere regras de CGNAT a
medida que os Pools vão sendo consumidos...
Mas tem que fazer LOG EXATO de quanto tira e coloca esse blocos na pilha do
CGNAT.
Bem no fim vira uma baita nojeira! Consegue juntar o pior das duas
opções... Ter que Manter log das alterações, e não ter alocação dinâmica.


Uma alternativa que você pode usar é fazer Pools básicos já contemplados
pelo CGNAT determinísitco.
E pools que não são contemplados pelo CGNAT Determinístico, mas são
cobertos por NAT overload(SRC-Nat comum) com definições de LOG de toda
conexão.
E usar algum mecanismo que colha e guarde esses LOGs.
Nesse caso, só vai fazer log quando estiver acima da MarcaDágua definida...
Se isso for recorrente, significa que tem que redimensionar o Pool Padrão.


 - Até aqui as possíveis respostas que você perguntou.
 --
 - Daqui pra baixo, colocações que não são o que você perguntou, mas que
podem te ajudar.


Mas SINCERAMENTE?
Os dois casos mencionados ali em cima são uma Gambiarra fudida!
Até funcionam mas logo-logo vão te azedar a vida.

Sugiro que se aprochegue ao conceito do Bulk Port Allocation.
https://wiki.brasilpeeringforum.org/w/CGNAT_Bulk_Port_Allocation_com_DPDK
Com o mesmo dinheiro de uma CCR1036 você compra um server x64 e coloca mais
tráfego em cima!

P.S.: Não compre nada lançado antes de 2015! Vai passar raiva!


Em ter., 9 de mar. de 2021 às 15:33, Tiago SR <listas at tiagosr.com> escreveu:

> Prezados,
>
> Alguém tem uma ideia para CGNAT determinístico quando a rede é composta de
> vários /24s da RFC1918, utilizados parcialmente e de forma desordenada (10
> a 60 endereços em cada um, espalhados por todo o bloco de forma não
> sequencial)?
>
> Cada PoP ou ponto de acesso que a gente implanta na rede, nós jogamos um
> /24 privado da RFC1918 para ele, para distribuir por DHCP.
> Tem alguns concentradores regionais, mas queremos fazer o CGNAT
> centralizado. O NAT já é centralizado, só mudar para CGNAT.
>
> Os problemas que estou tendo são:
>
> 1) se eu mapear (netmap) um /24 privado para um range de 2000 portas de um
> /24 público, eu vou estar alocando portas para IPs privados que não são
> usados atualmente e provavelmente nem nunca serão, porque esses /24 nunca
> chegam nem perto de lotar (só são usados uns 60 ou menos dos seus
> endereços), então é desperdício e provavelmente teria o mesmo problema
> seguinte
>
> 2) para resolver esse problema anterior, fiz algo tipo uma alocação
> dinâmica, em que ao invés de mapear ranges privados, são mapeados address
> lists de até 1000 IPs individuais captados pelo firewall. Uma address list
> para cada range de 2000 portas, 32 address lists. Usei action=same para
> mapear a address list para o bloco de IPs públicos e suas respectivas
> portas, conforme a regra a seguir, mas o problema é que alguns IPs não são
> pegos no action=same e ficam sem funcionar. Exemplo: IP privado 10.90.0.17,
> bloco público 198.51.100.0/22. Parece que o funcionamento é semelhante ao
> action=netmap, aí a parte de host desse IP 10.90.0.17 aplicando máscara /22
> não corresponde com uma parte que host que possa ter no 198.51.100.0/22 e
> fica sem NAT...
>
> Ex. de uma regra do NAT: /ip firewall nat add chain=srcnat
> src-address-list=cgnat32-1_1024-3024 protocol=tcp action=same
> same-not-by-dst=yes to-addresses=198.51.100.0/22 to-ports=1024-3024
>
> Tem rede com /24s de todo jeito, uma salada, ex.: 10.90.0.0/24,
> 10.0.2.0/24, 172.31.110.0/24. Não é viável mudar essas redes, reendereçar
> tudo e ajustar a autenticação de todos dispositivos, são cerca de 200
> redes...
>
> Alguma ideia de como resolver isso com RouterOS? Sei que provavelmente uma
> implementação de Bulk Port Allocation de uma solução fechada resolva, mas
> não vai rolar por agora, e espero que nem nunca, já que a ideia é jogar o
> máximo para IPv6.
>
> Agradeço desde já por sua atenção e contribuição, colegas.
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>


-- 
Douglas Fernando Fischer
Engº de Controle e Automação