[GTER] Solução de mapeamento de portas de origem com bloco CGNAT para RouterOS

[Douglas Fischer]

Cara, nunca me esforcei para ver isso nos MK da vida, mas a Cisco por
exemplo tem uma abordagem "pré-moldada" para CGNat.

Na hora de configurar você diz os possíveis sources, pool dos IPs quentes,
alguns atributo mais, e ele monta tudo para você...


Será que não existe nada assim para o MK?


Em 21 de dezembro de 2015 10:26, Fabiano Ribeiro <
fabiano.ribeiro at gerenciatec.com.br> escreveu:

> Bom dia pessoal,
>
>     Eu estou desenvolvendo uma solução de mapeamento de portas para
> resolver a situação de provedor que está quase superando a quantidade de
> ips públicos que possui e não pode ainda pegar um novo bloco /22. A idéia é
> usar um range de portas de origem de um IPv4 público e mapear para um IPv4
> privado do bloco da RFC6598. Inclusive encontrei uma discussão bem legal
> aqui na GTER em que o Rubens Kuhl comenta sobre essa solução em Linux.
>     Creio que uma solução dessa em um VyOS, EdgeOS com conntrack-sync, ou
> um freebsd com pfsync seja uma solução mais interessante do que com
> RouterOS, pois permitiria uma alta disponibilidade sincronizando a tabela
> de NAT caso funcione corretamente. Mas devido a base de RouterOS que temos
> eu estou tentando criar algo assim para aproveitar as Routerboards para
> esse tipo de fim.
>      Diferente do iptables, o firewall do RouterOS só permite mapeamento de
> portas para os protocolos TCP e UDP, qualquer outro protocolo somente o IP
> pode ser alterado.
>      Para ilustrar e ficar mais fácil o entendimento do que estou dizendo,
> as regras ficariam mais ou menos assim:
>
> #######
>
> /ip firewall nat
>
> add action=jump chain=srcnat dst-address-list=!locais
> jump-target="mapeamento 100.64.0.0/26" src-address=100.64.0.0/26
> add action=jump chain=srcnat dst-address-list=!locais
> jump-target="mapeamento 100.64.0.64/26" src-address=100.64.0.64/26
>
> add action=src-nat chain="mapeamento 100.64.0.0/26" protocol=tcp
> src-address=100.64.0.1 to-addresses=1.1.1.1 to-ports=1000-1999
> add action=src-nat chain="mapeamento 100.64.0.0/26" protocol=udp
> src-address=100.64.0.1 to-addresses=1.1.1.1 to-ports=1000-1999
> add action=src-nat chain="mapeamento 100.64.0.0/26" protocol=tcp
> src-address=100.64.0.2 to-addresses=1.1.1.1 to-ports=2000-2999
> add action=src-nat chain="mapeamento 100.64.0.0/26" protocol=udp
> src-address=100.64.0.2 to-addresses=1.1.1.1 to-ports=2000-2999
> (restante das regras...)
> add action=src-nat chain="mapeamento 100.64.0.0/26" to-addresses=1.1.1.1
>
> add action=src-nat chain="mapeamento 100.64.0.64/26" protocol=tcp
> src-address=100.64.0.64 to-addresses=1.1.1.2 to-ports=1000-1999
> add action=src-nat chain="mapeamento 100.64.0.64/26" protocol=udp
> src-address=100.64.0.64 to-addresses=1.1.1.2 to-ports=1000-1999
> add action=src-nat chain="mapeamento 100.64.0.64/26" protocol=tcp
> src-address=100.64.0.65 to-addresses=1.1.1.2 to-ports=2000-2999
> add action=src-nat chain="mapeamento 100.64.0.64/26" protocol=udp
> src-address=100.64.0.65 to-addresses=1.1.1.2 to-ports=2000-2999
> (restante das regras...)
> add action=src-nat chain="mapeamento 100.64.0.64/26" to-addresses=1.1.1.2
>
> #######
>
>    Por tudo que já avaliei eu creio que mapeando as portas UDP e TCP seja o
> suficiente para resolver qualquer decisão judicial que o provedor venha a
> receber, mas gostaria da opinião dos colegas sobre esse assunto: Alguém já
> implementou algo parecido ? Alguém vê um risco de usar esse tipo de solução
> ?
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter




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