[GTER] [BPF] RES: Morte às mensagens de NAT tipo 3 - DANOS - CGNAT OpenSource com BPA EIM/EIF e UPnP/PCP

Fri Jul 24 10:49:35 -03 2020

- Hardware: CCR-1072
- CGNAT: Determinístico
- Razão de compartilhamento: 1:32
- Throughput: +- 18G (em horários de pico)
- Pps: 1.5M (em horários de pico)
- CPU: 25% (em horários de pico)
- Uptime: 62 dias (OS Update)
- PRC: 0% (Percentual de Reclamações de Clientes) 

Para minimizar o uso de CGNAT, temos reservas para:

- Dedicados
- Dinâmicos 

Utilizados quando:
- Dedicados via contrato com diferencial financeiro
- Dinâmicos quando há necessidade explicita de uso, ou há reclamações
por parte do cliente, que tornando evidente a necessidade. 

Até o momento vai muito bem obrigado! 

Mas... como sei que não vai ser semana que vem que teremos IPv6, vamos
ter que conviver com CGNAT um bom tempo, sinceramente acredito que em
algum momento no futuro (se ainda estiver neste ramo) vou ter que
procurar outras soluções de CGNAT. 

Gosto muito da ideia do método com BPA, mais não sou simpatizante de
logs (não nesse volume), Flows não seriam melhores até para não onerar
tanto a caixa fazendo CGNAT?  

Me chamou atenção esse comentário na doc:

"Note that enabling session logging will switch CGNAT to record
destination address and port in sub-sessions (2-tuple sessions in tables
within 3-tuple sessions).  This will affect performance." 

Em 2020-07-24 10:23, Vinicius Gruske Dorneles escreveu:

> Eu entendo que o BPA se refere ao método de alocação de portas para o
> src-nat, e concordo que cada uma dessas conexões que você apontou Douglas,
> são únicas.
> 
> Eu estava achando que o que estava em discussão era um método mágico de
> dst-nat dinâmico para de trás da CPE (pro console/DVR). O Fernando deixou
> claro que não se trata disso. Entendi que a discussão se trata
> exclusivamente de portas auxiliares para SIP/FTP/DCCP/etc.
> 
> Então lhe pergunto Douglas, sei que você é um tanto crítico ao Mikrotik
> (não que eu não tenha minhas críticas e longe de querer pregar por aqui),
> mas já usou/experimentou o RouterOS como CGNAT? O RouterOS possui NAT
> Helpers (FTP, h323, irc, PPTP, udplite, dccp, sctp, SIP, tftp), e de
> experiência própria com CGNATs, já tive problemas no VyOS com o protocolo
> SIP, mas nunca tive no RouterOS.
> 
> Em sex., 24 de jul. de 2020 às 10:00, Douglas Fischer <
> fischerdouglas at gmail.com> escreveu:
> 
> Bom dia Vinicius!
> Sinceramente fiquei um pouco confuso com o que descreveu.
> 
> Se o que eu entendi é o que você está mesmo pensando, acho que estás com
> uma confusão de conceito.
> 
> Uma conexão TCP(ou stream UDP) depende de 4 datores para ser única!
> IP de destino + Porta de destino + IP de Origem + Porta de Origem.
> 
> Vou tentar exemplificar...
> |   SrcIPGCNAT | SRCPortGCNAT | SrcIPPublico | SrcPortPublico |
> DstIPPublico | DstPortPublico |
> | 100.64.10.11 |        32467 | 200.10.20.30 |          10001 |
> 80.80.80.80 |            443 |
> | 100.64.10.12 |        48333 | 200.10.20.30 |          20001 |
> 80.80.80.80 |            443 |
> | 100.64.10.13 |        55873 | 200.10.20.30 |          30001 |
> 80.80.80.80 |            443 |
> | 100.64.10.14 |        12799 | 200.10.20.30 |          40001 |
> 80.80.80.80 |            443 |
> | 100.64.10.15 |        22557 | 200.10.20.30 |          50001 |
> 80.80.80.80 |            443 |
> 
> Cada uma dessas é uma conexão única!
> 
> Em sex., 24 de jul. de 2020 às 09:34, Vinicius Gruske Dorneles <
> viniciusgruske at gmail.com> escreveu:
> 
> Então, até onde eu tenho conhecimento não existe problema em conexões
> saintes em aplicações que "não se importam" com a porta de origem. Como o
> Douglas comentou lá no início, a maior dor de cabeça são as "CONEXÕES
> ENTRANTES AUXILIARES formadas para comunicação Peer-to-Peer".
> Quando se tem uma IP Público na CPE, o UPnP resolve o mapeamento para o
> console. Por exemplo, experimente colocar dois consoles atrás do mesmo IP
> Público. O UPnP não vai conseguir alocar duas portas públicas para
> diferentes IPs privados.
> Eu entendo que a alocação do BPA seja dinâmica, e entendo que existem 65535 portas. MAS, em um /22, só existe 1024 portas tcp/8080, só 1024 portas
> udp/9090. O número de porta específica é igual ao número de endereços
> disponíveis. Se você quiser fazer o redirecionamento do DVR pros teus 1000 clientes, e tu só possui um /23 alocado para CGNAT, só 512 clientes poderão usar a porta default/well-know (que se não me engano é a tcp/8080).
> 
> A minha dúvida sobre o NAT BPA é sobre o como ele traduz. Vamos dizer que
> eu tenho uma CPE com o IP 100.64.220.30. No método Predefined, eu sei que
> ele vai sair sempre pelo mesmo IP público, o "45.X.220.30" e usando o range de portas definidas (ex.: 1024-5055).
> Já no BPA, o que vai acontecer?
> Cenário 1: Ele vai traduzir pro mesmo IP sempre (ex.: "45.X.220.30") usando portas dinâmicas (ex.: 1024-65535);
> Cenário 2: ou vai usar um IP dinâmico (ex.: "45.X.220.0/22") e porta
> dinâmica (ex.: 1024-65535)?
> 
> Por que no cenário 1, continuamos com o mesmo problema análogo a dois
> console na mesma CPE. Se você faz um CGNAT 1:16, dos 16 clientes que tu
> atende com aquele IP Público, somente um cliente poderá ter o
> redirecionamento para o console/DVR dele. Os outros 15, se quiserem abrir a mesma porta, ainda vão enfrentar o problema do NAT.
> Já no cenário 2, ainda temos o mesmo problema do cenário um, mas é muito
> mais difícil de acontecer, porque terá que ser gasto todo o pool de
> endereços antes de ter o esgotamento da porta específica. E para
> complementar (se for esse o cenário), ainda tem o problema de uma mesma
> conexão, em portas auxiliares, terem IPs de origem diferentes. Isso também seria resolvido pelo BPA?
> De qualquer forma, ambos os cenários, não resolvem o problema de fato que
> é: não tem porta específica para todo mundo, da mesma forma que não tem
> IPv4 para todo mundo.
> E ainda trás um outro problema que não (costuma ter) em CGNAT predefined. É o "uma hora funciona, uma hora não funciona". É possível que num
> determinado horário, a porta vai estar livre para uso, e o NAT BPA vai
> fazer sua mágica e permitir a conexão entrante no console/DVR. Em um
> determinado horário a porta não estará disponível, e então, não será
> possível fazer a conexão entrante no console/DVR. No predefined, não vai
> ter essa inconsistência, pois ele não irá funcionar. Eu digo por
> experiência própria que "uma hora funciona, uma hora não funciona" é uma
> dor de cabeça que não desejo a ninguém. Eu já tive o azar de pegar um
> "gamer" que estava em um range do predefined, do mesmo range de porta de
> que o console precisava, e portanto, acontecia de que uma hora o maldito
> jogo funcionava, outra hora, não funcionava. O que eu fiz? Mudei ele de IP (e consequentemente de range de porta), e nunca mais funcionou. Ele só
> parou de gastar 1 hora do tempo do suporte todo dia, quando eu fiz isso.
> 
> Nesse caso, eu estou junto com o Carvalho. O IPv4 deveria ser tratado como legado. O cliente quer acessar a camera dele? IPv6.
> 
> Em sex., 24 de jul. de 2020 às 02:51, Fernando Frediani <
> fhfrediani at gmail.com> escreveu:
> 
> Esqueça hospedagem de partidas e conexões entrantes em ambientes de CGNAT. 
> Muita gente acredita que produtos caros de CGNAT resolvem problemas de
> jogos por permitir hospedar partidas mas esaa é pura ilusão e uma esperança vazia.
> Se alguem prometer isso na hora de vender desconfie imediatamente.
> 
> Os CGNATs mais elaborados resolvem outros problemas ligados exclusivamente a conexões saintes, a ALGs, etc
> 
> Para hospedagem de partidas ou você tem IP Publico ou o jogo suporta o
> conceito de redevouz server ou de 'furar'  o CGNAT com o auxilio de um
> servidor externo. É o conceito que se usa para acessar DVRs com a
> funcionalidade Clous.
> 
> Fernando
> 
> On Fri, 24 Jul 2020, 00:57 Vinícius Dorneles, <
 viniciusgruske at gmail.com> 

> wrote:
> 
> Sobre o CGNAT BPA, eu tenho uma dúvida. Vamos imaginar o seguinte cenário: 
> 
> Um provedor que possua seus 5000 mil clientes e um /22, e reservou um
 /23 

>> exclusivamente para CGNAT;
>> 
>> (Já que estamos falando em Jogos) O jogo X, para iniciar o Hosting de
 uma 

>> partida no Console Y, usa a porta TCP/3000;
>> 
>> Por um Hyping ou acaso muito grande do jogo, 600 "gamers" do provedor
>> decidem iniciar simultaneamente o Hosting de uma partida do jogo X.
>> 
>> Teoricamente, vão chegar 600 solicitações de mapeamentos (dst-nat)
 para a 

>> porta TCP/3000, todavia, só existem 512 endereços públicos
 disponíveis 

> para fazer o mapeamento de porta 1:1 para o endereço de CGNAT.
> 
> A pergunta é: O que acontece com os outros 88 "Gamers"? Imagino eu
 que 

> ficariam com o "NAT tipo 3", certo?
> 
> *De: *Douglas Fischer <fischerdouglas at gmail.com>
> *Enviado:*quinta-feira, 23 de julho de 2020 14:56
> *Para: *Grupo de Trabalho de Engenharia e Operacao de Redes
> <gter at eng.registro.br>; bpf at listas.brasilpeeringforum.org
> *Assunto: *[BPF] Morte às mensagens de NAT tipo 3 - DANOS - CGNAT
> OpenSource com BPA EIM/EIF e UPnP/PCP
> 
> Eu escrevi essa montoeira de siglas ali em cima...
> Mas tenho certeza que o que chamou atenção dos coleguinhas foi a
 parte 

> do "Morte às mensagens de NAT tipo 3".
> -> 3 vivas para os tickets de suporte que os usuários de PSN e XBOX abrem por causa das mensagens de NAT Tipo 3, não é mesmo?
> 
> TL;DR:
> Se você manja bem dos paranauê de linux, nat/iptables e similares, e
 está 

>> disposto a fazer uma tentativa uma ferramenta opensource que promete
>> resolver muitos problemas que o CGNAT trás, eu gostaria de contar com
 sua 

>> ajuda! Arranje um servidor BOM(não bom venha com velharia) e "bora si
>> ajudá" a parar de passar raiva com CGNAT.
>> 
>> A importancia do CGNAT para ISPs no dia de Hoje
>> -----------------------------------------------
>> Se você está no mercado atual de ISPs e nunca ouviu falar de CGNAT,
 PARE 

> O 
> 
>> QUE ESTÁ FAZENDO E VÁ PROCURAR SABER SOBRE CGNAT!
>> Pois existe um grande risco de você estar fazendo as coisas de um
 jeito 

> errado, e logo-logo ter problemas legais por conta disso.
> 
> Se você já ouviu falar CGNAT, deve saber que existem basicamente 2
 tipos 

>> de CGNAT.
>> (vou ser muito muito muito conciso nessa descrição)
>> - Determinístico(ou Predefined) - Onde ranges de portas UDP e TCP de
 IPs 

>> Públicos/Válidos são préviamente alocadas para as conexões saintes de
> cada 
> 
>> um dos IPs de uso reservado do CGNAT.
>> 
>> A principal vantagem desse modelo é (se ele for implementado
>> corretamente) não precisar da guarda de LOGs.
>> 
>> - BPA - Bulk Port Allocation - Onde as portas vão sendo alocadas de
>> Tanto-em-Tanto para os   IPs de uso reservado do CGNAT conforme ele
 vai 

> precisando, e cada vez quem um grupo de portas é alocado, o mecanismo
 de 

>> CGNAT deve fazer um LOG disso, e esse log deve armazenado
 adequadamente. 

>> A principal vantagem desse modelo é o excelente nível de relação
 entre 

>> IPs Válidos/Públicos e os IPs reservados do CGNAT.
>> 
>> Os dois modelos tem vantagens, os dois modelos tem desvantagens...
>> Sinceramente sou adepto do BPA, pois apesar de exigir recursos extras
 de 

>> Log, tem uma melhor utilização das portas dos IPs públicos, e a
 alocação 

>> dinâmica reduz a dor de cabeça com usuários que usam muitas portas.
>> 
>> P.S.: Alerta de problemas jurídicos!
>> Uma coisa que tenho visto muito por aí é uma galerinha que tá fazendo
 uns 

>> mapeamento maroto sem uma lógica reversível e sem fazer log.
>> Quando chegar uma ordem judicial especificando
>> IPDeOrigem/PortaDeOrigem/DataeHora, e você não conseguir fazer a
>> identificação INEQUÍVOCA responsável do contrato daquele assinante...
>> A coisa tente a ficar feia pro seu lado... CUIDADO!
>> 
>> Aonde está a maior parte das dores que o CGNAT trás?
>> ----------------------------------------------------
>> CONEXÕES ENTRANTES AUXILIARES formadas para comunicação Peer-to-Peer.
>> Geralmente esses mapeamento de conexões auxiliares entrantes são
 feitos 

> ALGorítimos que ficam escutando as comunicações nas portas
 determinadas e 

>> "preparam uma regrinha dinâmica" para conexão entrante...
>> 
>> Os protocolos mais comuns de ver isso são:
>> - SIP/H323
>> 
>> - FTP ativo/passivo
>> 
>> - DCCP(que é o que a maioria dos games usa)
>> 
>> Porém para esses ALGs funcionarem, além de o equipamento de NAT tem
 que 

> ter todos os ALGs habilitados, e a comunicação nesse protocolo de controle não pode ser criptografada.
> 
> -> Para exemplificar, SIP-ALG não vai funcionar se for SIP over TLS
> 
> (a não ser que ele abra a criptografia do TLS).
> 
> Para contornar essa complexidade que esse ALGs trazem para fazer
> funcionar o P2P com regras de firewall e CGNAT foram criados padrões
 e 

> protocolos como PCP/UPnP, EIM/EIF (antes era o NAT-PMP).
> 
> A ESPERANÇA
> 
> -----------
> 
> Já tem muito tempo que eu venho buscando uma solução OpenSource para CGNAT que concorresse com a soluções proprietárias como "A10/F5/Hillstone"
 para 

>> ambientes de CGNAT com suporte a BPA e PCP.
>> Inclusive eu e mais alguns amigos chegamos a propor um vakinha
 on-line 

> para comprar o desenvolvimento disso no formato OpenSource.
> 
> Bom... Felizmente acredito que tenhamos achado a solução OpenSource
 que 

> eu procurava...

https://danosproject.atlassian.net/wiki/spaces/DAN/pages/421101573/CGNAT+and+PCP

> Ainda estou preparando um ambiente de testes dessa ferramenta.
> Mas estou bastante otimista com o que pude ver dela.
> 
> Dentre a diversas coisas boas que posso falar sobre esse projeto, é
 que 

> mesmo sendo opensource ele tem uns empurrõezinhos de grandes ISPS e
> carriers como a AT&T.
> 
> O PEDIDO DE AJUDA
> -----------------
> No momento, a melhor maneira que eu encontrei de ajudar esse projeto
> OpenSource é fazer um apelo aos colegas brasileiros que tenham
 expertise 

>> para manter um ambiente de NAT em Linux, que mantenham redes de ISP
 que 

> usem CGNAT, e que queiram ajudar a validar se essa ferramenta é
 realmente 

>> tão PORRETA, colocando ele para rodar em algum ambiente de teste e
>> compartilhando com o pessoal do projeto o resultado.
>> 
>> NÃO É UMA TELA DO WINBOX
>> 
>> ------------------------
>> Minha sugestão sobre a quem seria indicado embarcar nesses testes.
>> 
>> P.S.: Antes que venham me achincalahar de metido... Já adianto:
>> 
>> Estou pedindo a colaboração aqui na lista porque, sendo sicero, tenho
>> dúvidas se eu tenho conhecimento técnico suficiente para segurar esse
> rojão. 
> 
>> E também porque sei que temos vários colegas aqui na lista que tem um
>> nível Master-Pica-Jedi e que conseguiriam lidar com os prossíveis
> problemas 
> 
>> que surgirão com se estivessem descascando amendoim.
>> 
>> - Se for querer usar um hardware velharia/lixo, com mais de 10-12
 anos... 

>> Fora da lista de compatibilidade do projeto.
>> ou
>> 
>> - Se você não tem um bom conhecimento para conseguir fazer
> troubleshooting 
> 
>> em ambientes mais elaborados de Fowarding, NAT, e Firewall de Linux.
>> 
>> -> NÃO SE META!
>> Você vai passar raiva...
>> 
>> Depois vai pedir ajuda...
>> 
>> Vai fazer os coleguinhas passarem raiva,
>> 
>> que irão usar palavras pesadas com você...
>> 
>> E depois você vai sair falando baoseiras sobre o projeto!
>> 
>> Ao meu entender o projeto é bastante robusto e maduro!
>> Mas nesse momento ainda não é algo que esteja mastigadinho no nível
>> "tutorial do underlinux ou do vivaolinux" que seja só copiar e
 colar... 

> --
> 
> Douglas Fernando Fischer
> Engº de Controle e Automação
> 
> _______________________________________________
> bpf mailing list
> bpf at listas.brasilpeeringforum.org
> https://listas.brasilpeeringforum.org/mailman/listinfo/bpf
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
 --
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 

-- 
Att 

Márcio Elias Hahn do Nascimento

 [1] 

Links:
------
[1] http://www.sulinternet.net