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

Fri Jul 24 09:49:42 -03 2020

Vinicius, não é assim que funciona CGNAT com BPA.

BPA apenas aloca intervalos de portas de *saída* e não importa muito 
qual porta de origem a aplicação o cliente originou a conexão, elas 
sairão para internet com o(s) range(s) que for(ram) alocados pelo 
equipamentos de CGNAT. Se o console/jogo tentou hospedar uma partida e 
pediu ao UPnP para abrir uma porta a CPE dele vai fazer corretamente mas 
o equipamento de CGNAT vai ignorar porque não é função dele fazer isso.
Não confunda redirecionamento de entrada com Bulk Port Allocation que é 
a capacidade do equipamento alocar intervalos de porta dinamicamente sob 
demanda do cliente. CGNAT com BPA não tem a ver com "abertura de portas 
de entrada".

O que acontece é que geralmente equipamentos que são capazes de fazer 
Bulk Port Allocation são também capazes de fazer EIM/EIF, os ALGs 
funcionam corretamente, e isso acaba resolvendo outros problemas 
relacionados à NAT.

Se o cliente está atras de CGNAT esqueça hosting the partidas a não ser 
que o próprio jogo suporte isso através de outras técnicas como redevouz 
server hospedado por eles e consegue furar o NAT justamente através 
desses portas de origem que o BPA (ou o CGNAT Port Fixed) alocam para o 
cliente.

Fernando Frediani

On 24/07/2020 09:33, Vinicius Gruske Dorneles wrote:
> 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