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

Fri Jul 24 18:27:06 -03 2020

Tenho ciência disso Fernando. 

Quanto aos logs, não é nem pela quantidade, mais sim pela necessidade de
armazenamento e criação de mecanismos de consultas posteriores. Caixas
como Cisco/Huawei geral Flows se não me engano, o que pode ser
interessante. 

Quanto ao melhor aproveitamento de portas, com certeza, é o principal
atrativo desta técnica! 

Em 2020-07-24 15:06, Fernando Frediani escreveu:

> On 24/07/2020 10:49, Márcio Elias Hahn do Nascimento wrote: 
> 
>> 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?
> Marcio, se a sua preocupação é a quantidade de logs creio que você pode ficar um pouco mais tranquilo com relação à isso. Os únicos logs gerados serão no momento que os blocos de portas são alocados e nada além disso. Não é uma quantidade tão grande assim considerando qualquer proporcionalidade do tamanho de operação.
> 
> E uma vantagem do BPA é que à médio em longo prazo você consegue economizar um número maior de endereços IPv4 Públicos por conseguir compartilhar um menor número de endereços entre mais clientes de maneira mais flexível.
> 
> Fernando
> 
> 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
 --
gter list    https://eng.registro.br/mailman/listinfo/gter 

-- 
Att 

Márcio Elias Hahn do Nascimento
 [1] 

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