[GTER] Solução de mapeamento de portas de origem com bloco CGNAT para RouterOS
Fabiano Ribeiro
fabiano.ribeiro at gerenciatec.com.br
Tue Dec 22 10:55:27 -02 2015
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
>
More information about the gter
mailing list