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

[Douglas Fischer]

O grande lance da "economia de IPs públicos" do BPA é não ter que alocar
Ranges de Portas Públicas para IPs não utilizados...

Por exemplo um ISP com 5K clientes em CGNAT rodando isso com 3 CCR 1036 com
B-RAS.
(acho que é um cenário bem comum né no brasilzão, né?)

Aí existem muitas opções... Atribuir IP pelo Radius ou pelo Pool Local do
B-RAS.

Mas mesmo que seja num pool centralizado, o ISP vai colocar ali pleo menos
uns 8K IPs para o Pool.

Se for Predefined, e o IP tá no Pool, o mapeamento de portas tem que estar
alocado!
Se não for assim alguém fez alguma gambiarra e não contou pro tio!

Bom, 3K IPs de CGNAT de "folga", se dermo 2048 portas para cada IP.
Gastaremos 94 IPs públicos para IPs de CGNAT que não estão sendo usados...





E isso, que nós só falamos do que se perde com a alocação para IPs não
utilizados.
Se for considerar que muitos clientes não usam nem 512 portas
simultaneamente (isso é claro num ambiente que bem caprichadinho, com IPv6
e bypass de CGNAT).
O "desperdício" de IP Público fica maior ainda.




Em sex., 24 de jul. de 2020 às 15:06, Fernando Frediani <
fhfrediani at gmail.com> 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
>


-- 
Douglas Fernando Fischer
Engº de Controle e Automação