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

Sexta Julho 24 14:10:16 -03 2020

Boa tarde sim claro vamos la

No persistent nat ele tenta preservar ao máximo a porta exemplo:

Cliente acessando o google:

Usando perisitent nat /EIM exemplo  na porta dst 53 (nao levem a porta ao
pé da letra ja que a 53 nao necessita de EIM ou Stun :
100.64.0.10:23453 > 8.8.8.8:53 >saido cliente para internet
200.200.0.10:23453 >   8.8.8.8:53 > nat saindo pra inernet

Usando BPA  exemplo  na porta dst 53
100.64.0.10:23453 > 8.8.8.8:53 >saido cliente para internet
200.200.0.10:13456>   8.8.8.8:53 > nat saindo pra inernet

A tahh mas giovaneli se a porta estiver sendo usada ?
R:A porta vai dar como ocupada , sendo necessária gerar uma nova.

Isto afeta na experiência do cliente:
R:Não afeta em absolutamente nada ate o momento

Mas porque então não usar EIM em tudo?
R: Alguns routers ou firewall não tem este recurso, sendo o persistente nat
seletivo uma boa opção.

No BPA automaticamente a porta é traduzida, no caso do persistent ele
mantém a mesma porta q o cliente pediu inicialmente até a internet, com
isso matando o nat tipo 3, ai faço isso somente para serviços específicos.

https://www.blackhole-networks.com/SRXNAT/snat_pool_no_PAT.html  este site
tem uma exelente explicação que gosto de passar para nossos alunos.
Segue um pedaço da saida

[edit security nat source]
juniper em SRX# run show security flow session
Session ID: 5342, Policy name: ACCEPT-LOG/4, Timeout: 300, Valid
  In: 192.168.200.87/*42724* --> 10.80.80.80/80;tcp, If: ge-0/0/4.0,
Pkts: 141, Bytes: 7471
  Out: 10.80.80.80/80 --> 10.80.80.200/*42724*;tcp, If: ge-0/0/3.0,
Pkts: 470, Bytes: 664464

Session ID: 5343, Policy name: ACCEPT-LOG/4, Timeout: 300, Valid
  In: 192.168.200.88/*33172* --> 10.80.80.80/80;tcp, If: ge-0/0/4.0,
Pkts: 141, Bytes: 7471
  Out: 10.80.80.80/80 --> 10.80.80.201/*33172*;tcp, If: ge-0/0/3.0,
Pkts: 470, Bytes: 664464

Session ID: 5344, Policy name: ACCEPT-LOG/4, Timeout: 300, Valid
  In: 192.168.200.89/52414 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0,
Pkts: 141, Bytes: 7471
  Out: 10.80.80.80/80 --> 10.80.80.202/52414;tcp, If: ge-0/0/3.0,
Pkts: 470, Bytes: 664464

Session ID: 5345, Policy name: ACCEPT-LOG/4, Timeout: 300, Valid
  In: 192.168.200.86/34579 --> 10.80.80.80/80;tcp, If: ge-0/0/4.0,
Pkts: 142, Bytes: 7523
  Out: 10.80.80.80/80 --> 10.80.80.203/34579;tcp, If: ge-0/0/3.0,
Pkts: 470, Bytes: 664464
Total sessions: 4

[edit security nat source]

Obrigado

Em sex., 24 de jul. de 2020 às 13:43, Douglas Fischer <
fischerdouglas em gmail.com> escreveu:

> 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
>

-- 

(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.
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://listas.brasilpeeringforum.org/pipermail/bpf/attachments/20200724/c2209512/attachment-0001.html>