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

Douglas Fischer fischerdouglas at gmail.com
Fri Jul 24 09:59:36 -03 2020 

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

More information about the gter mailing list