[GTER] [BPF] RES: Morte às mensagens de NAT tipo 3 - DANOS - CGNAT OpenSource com BPA EIM/EIF e UPnP/PCP
Fernando Frediani
fhfrediani at gmail.com
Fri Jul 24 15:06:26 -03 2020
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
>
More information about the gter
mailing list