[GTER] [BPF] RES: Morte às mensagens de NAT tipo 3 - DANOS - CGNAT OpenSource com BPA EIM/EIF e UPnP/PCP
Vinicius Gruske Dorneles
viniciusgruske at gmail.com
Fri Jul 24 10:23:29 -03 2020
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
>
More information about the gter
mailing list