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

[Lucas Willian Bocchi]

Não entendi o quê você quis dizer Fabiano: você pode utilizar CALEA
com o armazenamento de logs e sem. Inclusive pode até utilizar um
servidor centralizado para isso.

Calea é a solução completa do mikrotik para este tipo de cenário. Até
participei de um MUM sobre o assunto.

Em 22 de dezembro de 2015 10:55, Fabiano Ribeiro
<fabiano.ribeiro at gerenciatec.com.br> escreveu:
> Leonardo,
>
>    Sim, a questão é se há algum tipo de brecha que possa ser explorado em
> algum protocolo que não utilize TCP ou UDP. Mas acredito que o CGNAT irá
> sofrer do mesmo problema.
>
> Lucas,
>
>     Eu até cogitei essa solução, mas como tinha a possibilidade de não
> guardar logs eu preferi.
>
> Douglas,
>
>      Pois é. A Mikrotik bem que podia, mas infelizmente eles não tem
> implementado. Sobrou criar na mão mesmo :-(
>
> Bom eu vou fazer um teste piloto, vamos ver como será o comportamento do
> RouterOS.
>
> Obrigado pela ajuda pessoal !!
>
> Em 21 de dezembro de 2015 18:35, Douglas Fischer <fischerdouglas at gmail.com>
> escreveu:
>
>> 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
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter