Mudanças entre as edições de "CGNAT Bulk Port Allocation com DPDK"
Linha 117: | Linha 117: | ||
<code>'''# set protocols bgp 53XXX parameters router-id 186.xxx.xxx.163'''</code> | <code>'''# set protocols bgp 53XXX parameters router-id 186.xxx.xxx.163'''</code> | ||
+ | |||
+ | == <big>Roteamento estático para o BNG:</big> == | ||
+ | Aqui definimos as rotas estáticas para o BNG no IP 192.168.254.98, conforme nosso diagrama do artigo. Também pode ser feito por exemplo com iBGP mas para simplificar o artigo, coloquei como sendo rotas estáticas. | ||
+ | |||
+ | <code>'''# set protocols static route 100.64.0.0/22 next-hop 192.168.254.98'''</code> | ||
+ | |||
+ | <code>'''# set protocols static route 100.64.8.0/22 next-hop 192.168.254.98'''</code> | ||
+ | |||
+ | <code>'''# set protocols static route 100.64.12.0/22 next-hop 192.168.254.98'''</code> | ||
+ | |||
+ | <code>'''# set protocols static route 100.64.16.0/22 next-hop 192.168.254.98'''</code> | ||
+ | |||
+ | == <big>Definindo blackholes para evitar ataques de static loop:</big> == | ||
+ | Fazemos isso para evitar os ataques à IPs que não estão conectados mas que existem rotas para eles. Nesse caso definimos um blackhole para cada prefixo de IPv4 público que usaremos no nosso CGNAT. | ||
+ | |||
+ | <code>'''# set protocols static route 198.51.100.0/24 blackhole'''</code> | ||
+ | |||
+ | == <big>Entrando na configuração do CGNAT:</big> == | ||
+ | Agora começaremos a configuração do nosso CGNAT. Basicamente vamos definir quem são os pools de IPs privados usados no CGNAT (100.64.0.0/10), os pools de IPv4 públicos que serão usados no NAT e a configuração propriamente dita do cgnat dentro do DANOS. Vamos começar então: | ||
+ | |||
+ | Os pools CGNAT: | ||
+ | |||
+ | <code>'''# set resources group address-group AG_MATCH address 100.64.0.0/22'''</code> | ||
+ | |||
+ | <code>'''# set resources group address-group AG_MATCH address 100.64.8.0/22'''</code> | ||
+ | |||
+ | <code>'''# set resources group address-group AG_MATCH address 100.64.12.0/22'''</code> | ||
+ | |||
+ | <code>'''# set resources group address-group AG_MATCH address 100.64.16.0/22'''</code> | ||
+ | |||
+ | O pool IPv4 público que será feito NAT de saída. Nessa parte da configuração abaixo além da definição do prefixo público que usaremos, utilizei a configuração de até 8 blocos de 512 portas tcp/udp por assinante. Fiz isso porque em meus testes muitos assinantes estouravam a configuração de até 8 blocos de 256 portas tcp/udp e quando isso ocorre o cliente tem problemas de acesso. Mesmo utilizando esse perfil de até 4096 portas tcp/udp por assinante, a economia de IPv4 público ainda assim é muito grande porque a maioria dos clientes utilizam muito menos que 1024 portas tcp/udp durante o uso da Internet. Também por boa prática setamos o início das portas em 1024 e finalizando em 65535. Essa parte precisa ser bem definida porque mudanças no '''dynamic-block-allocation block-size''' e '''dynamic-block-allocation max-blocks-per-subscriber''' requerem uma mudança grande de estratégia e por isso um reboot no sistema será necessário para efetivar essas alterações devido as sessões anteriores ainda estarem em uso. | ||
+ | |||
+ | <code>'''# set service nat pool NAT_POOL1 address-allocation round-robin'''</code> | ||
+ | |||
+ | <code>'''# set service nat pool NAT_POOL1 address-pooling paired'''</code> | ||
+ | |||
+ | <code>'''# set service nat pool NAT_POOL1 entry RANGE1 ip-address prefix 198.51.100.0/24'''</code> | ||
+ | |||
+ | <code>'''# set service nat pool NAT_POOL1 port allocation sequential'''</code> | ||
+ | |||
+ | <code>'''# set service nat pool NAT_POOL1 port dynamic-block-allocation block-size 512'''</code> | ||
+ | |||
+ | <code>'''# set service nat pool NAT_POOL1 port dynamic-block-allocation max-blocks-per-subscriber 8'''</code> | ||
+ | |||
+ | <code>'''# set service nat pool NAT_POOL1 port range end 65535'''</code> | ||
+ | |||
+ | <code>'''# set service nat pool NAT_POOL1 port range start 1024'''</code> | ||
+ | |||
+ | <code>'''# set service nat pool NAT_POOL1 select event port-block-allocation'''</code> | ||
+ | |||
+ | <code>'''# set service nat pool NAT_POOL1 type CGNAT'''</code> | ||
+ | |||
+ | Veremos agora a definição restante do nosso CGNAT. Abaixo habilitamos o log que precisaremos gerar e armazenar para futuras requisições jurídicas, criaremos uma policy para dizermos qual grupo de IPs privados usaremos no source do NAT (nesse caso '''AG_MATCH''') e qual o pool de IPs públicos usaremos na saída (nesse caso '''NAT_POOL1'''). Também são definidos alguns timeouts: | ||
+ | |||
+ | <code>'''# set service nat cgnat log event port-block-allocation'''</code> | ||
+ | |||
+ | <code>'''# set service nat cgnat policy POLICY match source address-group AG_MATCH'''</code> | ||
+ | |||
+ | <code>'''# set service nat cgnat policy POLICY priority 10'''</code> | ||
+ | |||
+ | <code>'''# set service nat cgnat policy POLICY translation pool NAT_POOL1'''</code> | ||
+ | |||
+ | <code>'''# set service nat cgnat session-timeout other established 30'''</code> | ||
+ | |||
+ | <code>'''# set service nat cgnat session-timeout other partially-open 20'''</code> | ||
+ | |||
+ | <code>'''# set service nat cgnat session-timeout tcp established 1800'''</code> | ||
+ | |||
+ | <code>'''# set service nat cgnat session-timeout tcp partially-open 240'''</code> | ||
+ | |||
+ | <code>'''# set service nat cgnat session-timeout tcp port 53 established 10'''</code> | ||
+ | |||
+ | <code>'''# set service nat cgnat session-timeout udp established 1800'''</code> | ||
+ | |||
+ | <code>'''# set service nat cgnat session-timeout udp partially-open 240'''</code> | ||
+ | |||
+ | Até então só criamos as configurações do CGNAT mas ainda não dizemos em qual interface devemos aplicá-las. Devemos aplicá-las na interface de saída que liga com o Router Borda: | ||
+ | |||
+ | <code>'''# set service nat cgnat interface dp0bond0 policy POLICY'''</code> |
Edição das 19h59min de 9 de novembro de 2020
Objetivo:
Mostrar a configuração do projeto DANOS para funcionar como um CGNAT Bulk Port Allocation utilizando um hardware de baixo custo e proporcionando uma enorme economia de IPv4 público, pois trabalha com alocação de portas TCP/UDP dinamicamente e não da forma Determinística onde pré-fixamos uma quantidade de portas por assinante. Temos que ter sempre em mente que a implantação e o uso do IPv6 é importantíssimo, porque o CGNAT não irá resolver todos os problemas da Internet. O CGNAT ajudará à manter a rede funcionando enquanto o IPv6 não for 100% utilizado no Mundo. O fato do projeto DANOS utilizar o DPDK, permite que consigamos usar um equipamento mais simples para gerenciar tráfegos bem maiores em Gbps/PPS.
Diagrama:
O BNG é o responsável por gerenciar as conexões PPPoE/IPoE e no nosso artigo fará o encaminhamento de todos os pacotes do pool CGNAT 100.64.0.0/10 via PBR (Policy Based Routing) para a caixa DANOS CGNAT. O DANOS CGNAT estará conectado via iBGP com o Router Borda e fará a tradução e alocação dinâmica das portas TCP/UDP usando como exemplo de saída o prefixo 198.51.100.0/24.Clientes conectados no BNG com IPv4 público e IPv6 não devem ser encaminhados para a caixa CGNAT.
Teremos uma rede lógica 192.168.254.0/24 entre os BNGs e o DANOS CGNAT e outra rede lógica 10.69.0.8/30 entre o DANOS CGNAT e o Router Borda. Usaremos os IPs das loopbacks para fecharmos o iBGP. O iBGP está sendo fechado somente de um lado para facilitar o artigo, mas cabe à você decidir a melhor forma de implementar em seu cenário.
Também usaremos nessa configuração um bonding (LACP) de duas portas de 10GbE para entrada de dados provenientes do Router Borda e outro bonding também com duas portas de 10GbE para a saída do tráfego em direção aos BNGs.
Embora esteja no diagrama, não falaremos sobre BNG e nem o Router Borda nesse artigo e por isso deve-se estudar como fazer o PBR em seu equipamento concentrador e também a configuração do iBGP no seu router pois será muito importante para o funcionamento da nossa caixa CGNAT.
Você pode adicionar outras caixas CGNAT basta seguir a mesma lógica apresentada aqui nesse artigo.
Descritivo sobre o DANOS:
É um projeto desenvolvido pelo pessoal da AT&T, que está atualmente na versão 2009, que utiliza o Vyatta como interface de configuração. A syntax me lembra bastante a configuração de um JunOS, possui diversos recursos semelhantes como commit, commit-confirm, validate para validar uma alteração dentre outras características. Por baixo do capô temos um sistema GNU/Linux Debian 10, Linux Kernel 5.4, FRR 7.3.1 e DPDK 19.11. O projeto possui utilidade inclusive para roteamento mas nesse artigo falaremos sobre CGNAT. Embora o sistema seja um Debian, não é disponibilizado uma atualização via apt, pois poderia quebrá-lo já que este possui partes não Debian incluídas no sistema como o DPDK. A atualização pode ser feita sempre que sai uma nova ISO do DANOS, através de comandos simples e salvando sua configuração atual.
Equipamento utilizado no artigo e em produção atualmente:
- Dell PowerEdge R230 - Quad Core Intel(R) Xeon(R) CPU E3-1240 v6 @ 3.70GHz.
- 16G ram.
- 2x Intel X520-SR2.
- SSD 120Gb.
Dados estatísticos desse equipamento em produção:
Atualmente passando 24Gbps agregado com mais de 1.5Mpps. Esse sistema tem 382 IPv4 públicos, 9980 clientes utilizando e mais de 50% dos IPs públicos ainda livres no CGNAT. Como o sistema utiliza DPDK, não temos como acompanhar visualmente a utilização dos processadores pois o dataplane ocupa todos eles ou quase todos durante seu uso mas essa é uma característica dele. Por isso temos que observar o comportamento do tráfego e erros que possam aparecer nas portas da switch e perdas de pacotes. Dessa forma estamos documentando o hardware utilizado em produção e quanto está suportando para usarmos de referência futura:
Instalação do DANOS:
Não vou falar sobre a instalação do sistema porque é extremamente simples. Não tem muitas opções durante a instalação, é feita através de um simples boot com um pendrive já com a ISO nele.
O passo à passo da instalação pode ser vista aqui. Basicamente é iniciar o boot e ao final dele executar: install image e responder as perguntas. Depois disso vamos para o nosso "mão na massa".
Começando a configuração:
Bem a primeira coisa é colocarmos os IPs nas interfaces para inclusive podermos acessar remotamente via ssh e também habilitar o serviço ssh. Vou utilizar uma configuração com IPv6 para fazer meu acesso remoto à esse sistema. Se você tiver outra interface reconhecida pelo sistema, você pode configurar um IP de gerência nela também e acessar por ali. No DANOS nem todas as interfaces de rede são reconhecidas e por isso você precisa consultar essa página e checar as suportadas. Também vamos configurar o bonding antes de configurarmos os IPs:
Após se logar com o usuário e senha que escolheu na instalação, basta executar o comando abaixo e passar os sets. Lembrando que os IPs que estou utilizando você deve alterar para o seu ambiente.:
$ configure
# set interfaces bonding dp0bond0 address '2804:XXXX:XXXX:faca:192:168:255:2/64'
# set interfaces bonding dp0bond0 address 10.69.0.10/30
# set interfaces bonding dp0bond0 mode lacp
# set interfaces bonding dp0bond1 address 192.168.254.1/24
# set interfaces bonding dp0bond1 mode lacp
# set interfaces dataplane dp0p1s0f0 bond-group dp0bond0
# set interfaces dataplane dp0p1s0f1 bond-group dp0bond0
# set interfaces dataplane dp0p2s0f0 bond-group dp0bond1
# set interfaces dataplane dp0p2s0f1 bond-group dp0bond1
# set protocols static route6 '::/0' next-hop '2804:XXXX:XXXX:faca::3'
Estamos definindo 2 bondings, sendo 1 pra cada interface de rede. Não faça bonding entre portas de interfaces de rede diferentes, isso prejudica o cpu affinity. Os nomes utilizados também possuem uma certa regra de criação e que pode ser vista digitando um "?" por exemplo:
# set interfaces bonding ?
Possible Completions:
> <dpFbondN> Bonding interface name
As 5 primeiras linhas criamos os bondings, definimos o mode lacp e colocamos os IPs. As 4 últimas linhas dizemos quais interfaces de rede fazem parte desse bonding e a última linha definindo o gateway default para o meu acesso IPv6 ao sistema.
Configuração do iBGP:
Vamos definir nosso endereço de loopback para usar no nosso iBGP com o Router Borda e setar uma rota apontando pro IP da loopback do Router Borda:
# set interfaces loopback lo address 186.xxx.xxx.163/32
# set protocols static route 186.xxx.xxx.160/32 next-hop 10.69.0.9
Agora vamos definir uma policy prefix-list para o prefixo que vamos anunciar no iBGP e outra prefix-list de rota default que só aceitaremos vindo do Router Borda:
# set policy route prefix-list bloco-publico rule 5 action permit
# set policy route prefix-list bloco-publico rule 5 prefix 198.51.100.0/24
# set policy route prefix-list rota-default rule 5 action permit
# set policy route prefix-list rota-default rule 5 prefix 0.0.0.0/0
Definição do policy route-map que usaremos:
# set policy route route-map router-IN rule 5 action permit
# set policy route route-map router-IN rule 5 match ip address prefix-list rota-default
# set policy route route-map router-IN rule 10 action deny
# set policy route route-map router-OUT rule 5 action permit
# set policy route route-map router-OUT rule 5 match ip address prefix-list bloco-publico
# set policy route route-map router-OUT rule 10 action deny
O que queremos é anunciar o prefixo público 198.51.100.0/24 para o Router e só aceitar receber dele o prefixo 0.0.0.0/0 assim:
# set protocols bgp 53XXX address-family ipv4-unicast network 198.51.100.0/24
# set protocols bgp 53XXX neighbor 186.xxx.xxx.160 address-family ipv4-unicast route-map export router-OUT
# set protocols bgp 53XXX neighbor 186.xxx.xxx.160 address-family ipv4-unicast route-map import router-IN
# set protocols bgp 53XXX neighbor 186.xxx.xxx.160 remote-as 53XXX
# set protocols bgp 53XXX neighbor 186.xxx.xxx.160 update-source lo
# set protocols bgp 53XXX parameters router-id 186.xxx.xxx.163
Roteamento estático para o BNG:
Aqui definimos as rotas estáticas para o BNG no IP 192.168.254.98, conforme nosso diagrama do artigo. Também pode ser feito por exemplo com iBGP mas para simplificar o artigo, coloquei como sendo rotas estáticas.
# set protocols static route 100.64.0.0/22 next-hop 192.168.254.98
# set protocols static route 100.64.8.0/22 next-hop 192.168.254.98
# set protocols static route 100.64.12.0/22 next-hop 192.168.254.98
# set protocols static route 100.64.16.0/22 next-hop 192.168.254.98
Definindo blackholes para evitar ataques de static loop:
Fazemos isso para evitar os ataques à IPs que não estão conectados mas que existem rotas para eles. Nesse caso definimos um blackhole para cada prefixo de IPv4 público que usaremos no nosso CGNAT.
# set protocols static route 198.51.100.0/24 blackhole
Entrando na configuração do CGNAT:
Agora começaremos a configuração do nosso CGNAT. Basicamente vamos definir quem são os pools de IPs privados usados no CGNAT (100.64.0.0/10), os pools de IPv4 públicos que serão usados no NAT e a configuração propriamente dita do cgnat dentro do DANOS. Vamos começar então:
Os pools CGNAT:
# set resources group address-group AG_MATCH address 100.64.0.0/22
# set resources group address-group AG_MATCH address 100.64.8.0/22
# set resources group address-group AG_MATCH address 100.64.12.0/22
# set resources group address-group AG_MATCH address 100.64.16.0/22
O pool IPv4 público que será feito NAT de saída. Nessa parte da configuração abaixo além da definição do prefixo público que usaremos, utilizei a configuração de até 8 blocos de 512 portas tcp/udp por assinante. Fiz isso porque em meus testes muitos assinantes estouravam a configuração de até 8 blocos de 256 portas tcp/udp e quando isso ocorre o cliente tem problemas de acesso. Mesmo utilizando esse perfil de até 4096 portas tcp/udp por assinante, a economia de IPv4 público ainda assim é muito grande porque a maioria dos clientes utilizam muito menos que 1024 portas tcp/udp durante o uso da Internet. Também por boa prática setamos o início das portas em 1024 e finalizando em 65535. Essa parte precisa ser bem definida porque mudanças no dynamic-block-allocation block-size e dynamic-block-allocation max-blocks-per-subscriber requerem uma mudança grande de estratégia e por isso um reboot no sistema será necessário para efetivar essas alterações devido as sessões anteriores ainda estarem em uso.
# set service nat pool NAT_POOL1 address-allocation round-robin
# set service nat pool NAT_POOL1 address-pooling paired
# set service nat pool NAT_POOL1 entry RANGE1 ip-address prefix 198.51.100.0/24
# set service nat pool NAT_POOL1 port allocation sequential
# set service nat pool NAT_POOL1 port dynamic-block-allocation block-size 512
# set service nat pool NAT_POOL1 port dynamic-block-allocation max-blocks-per-subscriber 8
# set service nat pool NAT_POOL1 port range end 65535
# set service nat pool NAT_POOL1 port range start 1024
# set service nat pool NAT_POOL1 select event port-block-allocation
# set service nat pool NAT_POOL1 type CGNAT
Veremos agora a definição restante do nosso CGNAT. Abaixo habilitamos o log que precisaremos gerar e armazenar para futuras requisições jurídicas, criaremos uma policy para dizermos qual grupo de IPs privados usaremos no source do NAT (nesse caso AG_MATCH) e qual o pool de IPs públicos usaremos na saída (nesse caso NAT_POOL1). Também são definidos alguns timeouts:
# set service nat cgnat log event port-block-allocation
# set service nat cgnat policy POLICY match source address-group AG_MATCH
# set service nat cgnat policy POLICY priority 10
# set service nat cgnat policy POLICY translation pool NAT_POOL1
# set service nat cgnat session-timeout other established 30
# set service nat cgnat session-timeout other partially-open 20
# set service nat cgnat session-timeout tcp established 1800
# set service nat cgnat session-timeout tcp partially-open 240
# set service nat cgnat session-timeout tcp port 53 established 10
# set service nat cgnat session-timeout udp established 1800
# set service nat cgnat session-timeout udp partially-open 240
Até então só criamos as configurações do CGNAT mas ainda não dizemos em qual interface devemos aplicá-las. Devemos aplicá-las na interface de saída que liga com o Router Borda:
# set service nat cgnat interface dp0bond0 policy POLICY