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

[Vinicius Gruske Dorneles]

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
>