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

Fabiano Ribeiro fabiano.ribeiro at gerenciatec.com.br
Mon Dec 21 10:26:28 -02 2015


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
?



More information about the gter mailing list