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

Sexta Julho 24 13:43:05 -03 2020

Opa Alexandre!

Nunca tinha pensado num cenário misto de Predefined e BPA.
O que geralmente faço é dar um Degrau Grande na primeira alocação(Ex.: 512
portas) e degraus menores nas alocações subsequentes (Ex.: 128 portas)
Com IPv6 de bypass de CGNAT(Severs de rede interna como DNS, e os Caches de
CDN), essas 512 portas abrangem uns 90% dos clientes...

Essa ideia de Predefined + BPA parece bem interessante!
Zera anecessidade de log inicial...
Mas impondo ainda a necessidade de um mecanismo de LOG(que na verdade é o
gosto amargo do BPA).

Confesso que não entendi a parte do Persistent NAT.
Mas fiquei muito interessado!
Me senti meio burrão pois reli umas vezes e não dei conta de entender.
Consegue exemplificar?

Em sex., 24 de jul. de 2020 às 13:12, Alexandre Giovaneli - Giovaneli <
alexandre em giovaneli.com.br> escreveu:

> Boa tarde
>
> Nós resolvemos este problema usando Juniper com DETERMINISTIC NAT + EIM
> ATIVO , em outros casos usando DETERMINISTIC NAT + PERSISTENT NAT , a parte
> de ALG já é padrão neste cenário . Temos outros cenários onde o cliente
> precisa de mais log usando a combinação PBA x4 (Significa que o cliente
> pode ter até 4 blocos de portas se necessário) +  PERSISTENT NAT
>
> Colocamos o  persistent nat em casos onde não tem o recurso de EIM para
> serviços que necessitam de  STUN, resolvendo o problema de NAT tipo 3 em
> todos os casos.
>
> O segredo então é na solução open-source é bem simples:
>
> Deterministic nat ou port bloco para gerar um número mínimo de log ou zero.
> Persistent nat ou qualquer outro recurso onde a porta não seja traduzida
> no cgnat (o que o cliente mandou tem que sair para internet com a mesma
> porta) somente para serviços ou portas que necessitem de STUN.
>
> Sendo mais mastigado assim:
>
> Para o persistent nat usar somente estas portas de destino.
> 3074 to 4500
> 1935
> 500
> 88
> 1863
> 42120 to 44325
> 5223
> 9988 to 20000
>
> E para o BPA ou  DETERMINISTIC NAT o restante do tráfego.
>
>
> Alguns desafios:
> Consulta simples e fácil do ip de outside e porta de outside
> Limite de seções isto é um problema em soluções open source.
> Throughput considerando que você não tem um chip ou "placa" para
> servidores que permita fazer isto inline (fazer o nat direto em uma FPGA
> por exemplo) e deixar somente o CPU fazer o plano de controle, então este
> tráfego deverá ser levado para cpu, e como sabemos toda arquitetura de
> servidores existe um limite de throughput entre cpu e barramento pcie.
>
> Um abração
>
>
>
>
>
>
>
>
> Em qui., 23 de jul. de 2020 às 14:56, Douglas Fischer <
> fischerdouglas em gmail.com> escreveu:
>
>> 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.
>>
>> <https://danosproject.atlassian.net/wiki/spaces/DAN/pages/421101573/CGNAT+and+PCP>
>>
>>
>> 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 em listas.brasilpeeringforum.org
>> https://listas.brasilpeeringforum.org/mailman/listinfo/bpf
>>
>
>
> --
>
>
> (PT) Esta mensagem pode conter informação confidencial ou privilegiada,
> sendo seu sigilo protegido por lei. Se você não for o destinatário ou a
> pessoa autorizada a receber esta mensagem, não pode usar, copiar ou
> divulgar as informações nela contidas ou tomar qualquer ação baseada nessas
> informações. Se você recebeu esta mensagem por engano, por favor, avise
> imediatamente ao remetente, respondendo o e-mail e em seguida apague-a. Agradecemos
> sua cooperação.
>
>
> (EN) This message may contain confidential or privileged information and
> its confidentiality is protected by law. If you are not the addressed or
> authorized person to receive this message, you must not use, copy, disclose
> or take any action based on it or any information herein. If you have
> received this message by mistake, please advise the sender immediately by
> replying the e-mail and then deleting it. Thank you for your cooperation.
>
>

-- 
Douglas Fernando Fischer
Engº de Controle e Automação
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://listas.brasilpeeringforum.org/pipermail/bpf/attachments/20200724/18ff7947/attachment-0001.html>