[GTER] Firewall no ASN

Thu Sep 20 18:50:17 -03 2018

Em 20/09/2018 16:48, Fernando Frediani escreveu:
> Bacana o seu relato Gondim, obrigado por compartilhar conosco.
>
> Quando for possível retirar as qeues do BRAS e controlar na OLT de 
> forma automatizada no provisionamento isso escala ainda mais hein !
Meu sonho é isso mas tem que ser bem feito para também não deixar o 
cliente burlar o controle.
>
> Duas perguntas:
> 1) como fica o tratamento do pacote se o destino for dentro do seu 
> backbone (Servidor, outro cliente de CGNAT, Servidores de CDN) ? Você 
> manda pra caixa que faz o CGNAT mesmo assim baseando-se apenas no 
> source-address 100.64.0.0/10 ou verifica também o destino ?
Roteamento pela origem 100.64.0.0/10. Se forem clientes de caixas 
diferentes, eles vão ao CGNAT e de lá vão para as caixas. Mas essa não é 
muito a nossa preocupação. Quando existe a necessidade de um cliente se 
falar com outro, normalmente nos casos que pegamos aqui são PJ e aí 
colocamos eles com IPv4 público ou em IPv6.

> 2) Esse servidor que faz o CGNAT faz determinístico ou chegaram a 
> implementar algum tipo de bulk allocation dinâmico ? Se sim, no caso 
> de bulk allocation como fica a parte de logs ?

Olha a gente tentou fazer de algumas formas. Algumas deram mais 
problemas que outras. Por exemplo separação por range de portas nos 
gerou problemas com clientes de jogos, mesmo separando 2000 portas por 
cliente. Alguns provedores já vi fixarem o IP privado por assinante e 
fazerem a separação por porta. Esse não funciona conosco porque nas 
nossas caixas temos ainda pools IPv4 públicos e pools de CGNAT. O 
cliente só pega o CGNAT se não tiver mais IPv4 público disponível na 
caixa. Por isso não podemos fixar os IPs deles. O modelo que, embora não 
seja o correto, mas foi o que menos deu dor de cabeça pra gente foi o de 
1 IPv4 público pra 32 IPv4 privados. Esse não gerou problema algum com 
as aplicações dos assinantes que trabalham com portas específicas e com 
a maioria dos jogos. Inclusive a febre do jogo LOL aqui funciona 
certinho. Quando você tiver um tempo instala o cliente do LOL e monitora 
quantas portas esse jogo dos infernos abre kkkkk pra mais de 1000 em uma 
partida.

>
> Agora entendi porque o IPv6 funciona redondinho ai. Firmware baseado 
> em OpenWRT é outro nível !

Sim com o Flashbox da Anlix o router é configurado automaticamente em 
dual stack IPv4/IPv6 querendo ou não kkkkk

>
> Fernando
>
>
> On 20/09/2018 00:35, Marcelo Gondim wrote:
>> Oi Douglas,
>>
>> Então aqui em uma das cidades que atendemos, a principal tenho 6 CCRs 
>> sendo 5 com 2000 assinantes conectados e planos que variam entre 
>> 10Mbps e 50Mbps. Nessa cidade o tráfego total no pico é de quase 
>> 9Gbps. Tráfego em cada CCR dessa perto dos 2Gbps. Uma outra CCR aqui 
>> só para clientes corporativos. Aqui trabalhamos para que o IPv6 seja 
>> o mais adotado possível pois nossos técnicos na instalação do 
>> assinante habilitam o dual stack. O novo sistema que estamos usando 
>> inclusive o router que levamos para o assinante já se auto provisiona 
>> e configura IPv4 e IPv6 sem intervenção do técnico. Para nós ficou 
>> muito melhor montar um servidor Linux com 2 interfaces Intel X520-SR2 
>> com 4 portas de 10GbE e direcionar apenas os clientes de CGNAT 
>> (100.64.0.0/10) para ele. Nosso objetivo aqui é um dia nem precisar 
>> mais do CGNAT e por isso contamos com a intensificação do uso do 
>> IPv6. Tudo é uma questão de planejamento. Como nós aqui fazemos FTTH, 
>> o router colocado no assinante é de nossa responsabilidade e com o 
>> recurso de auto provisionamento, acreditamos que cada vez mais o 
>> CGNAT será menos utilizado e não o contrário.  :)   Veja eu tenho 1 
>> servidor de CGNAT atendendo 5 CCRs e não 1 pra cada CCR.
>>
>> Uma outra cidade que atendemos aqui o tráfego é menor, 6Gbps e só de 
>> CGNAT o consumo é de uns 300Mbps. Nessa cidade são 5 CCRs e o 
>> restante dos acessos são IPv4 público e IPv6 e também fazemos a mesma 
>> coisa, um Linux fazendo o papel de CGNAT sendo que com 1 Intel X520-SR2.
>>
>> Mas é como você colocou, cada um faz a abordagem que melhor se 
>> enquadra ao seu cenário sem aquilo de certo ou errado, apenas a 
>> maneira que acha melhor.
>>
>> Em 19/09/2018 16:29, Douglas Fischer escreveu:
>>> Opa Marcelo!
>>> Eu pessoalmente não gosto dessa metodologia de separar o CG-NAT do 
>>> B-RAS.
>>>
>>> Prefiro tratar todas essas questões de filtragem e CG-NAT no próprio 
>>> B-RAS.
>>> Perder um pouco em performance, ganha em resiliência e escalabilidade.
>>>
>>>
>>> Falando de CCR, jogando CG-NAT no B-RAS(PPPoE server) você acaba 
>>> "perdendo"
>>> um pouco de capacidade nominal em número de clientes em banda.
>>> Se conseguia colocar 1500-1600 clientes, vai passar a colocar uns
>>> 1100-1200(talvez nem isso dependendo do perfil de cliente).
>>>
>>> Mas se estiver considerando um cenário com 2 B-RAS com 1500 clientes,
>>> e precisaria de uma 3ª e 4ª caixas só para fazer CG-NAT e sua 
>>> respectiva
>>> redundância...
>>> Pegue essas 4 caixas e coloque as 4 para fazer B-RAS+CG-NAT+Filtragens
>>> simples.
>>> Isso dá 750 clientes por caixa, ou 1000 clientes em caso de falha de 
>>> uma
>>> das caixas...
>>>
>>> Pro CG-NAT, já vai ter que está com o Contrack ligado mesmo!
>>> Então fazer algumas filtragens(Ex.: TCP/25, SSDP, etc) ali, não vai te
>>> tomar tantos ciclos de processamento a mais do que já está usando...
>>> (FastTrack pode ajudar bem a by-passar algumas coisas. RAW também.)
>>>
>>>
>>>
>>>
>>> Em ter, 18 de set de 2018 às 22:34, Marcelo Gondim 
>>> <gondim at bsdinfo.com.br>
>>> escreveu:
>>>
>>>> Essa abordagem que o Rubens colocou é a melhor mesmo. Aqui usamos 
>>>> assim:
>>>>
>>>>
>>>> BRAS ----- CGNAT ----- Router/Firewall --- Borda
>>>>    |                                      |
>>>>    +------------------------------+
>>>>                IPv6
>>>>
>>>> Em 18/09/2018 22:16, Rubens Kuhl escreveu:
>>>>> O recomendável é um terceiro equipamento entre esses dois, em
>>>> configuração
>>>>> não redundante.
>>>>>
>>>>> BRAS - Firewall - Borda
>>>>> +------------------------+
>>>>>
>>>>> Essa conexão direta entre BRAS e Borda é a que já existe hoje, e 
>>>>> seria
>>>>> contingência caso o firewall pife.
>>>>> Dá para fazer isso em L2 ou L3 à sua escolha... se for L2 com
>>>> spanning-tree
>>>>> de redundância, se for L3 com OSPF de redundância. Se for L2 com 
>>>>> firewall
>>>>> bridge, se for L3 com firewall roteado.
>>>>>
>>>>> Um servidor x86, rodando RouterOS, Linux ou FreeBSD seria um bom
>>>> candidato.
>>>>>
>>>>> Rubens
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Sep 18, 2018 at 9:04 PM Tárcio Dutra 
>>>>> <tarcio_dutra at hotmail.com>
>>>>> wrote:
>>>>>
>>>>>> Boa tarde, Turma.
>>>>>>
>>>>>>
>>>>>> Recentemente recebemos alguns avisos de "Os IPs abaixo são origem de
>>>>>> ataques DDoS", tais IPs são de alguns clientes, somos um ISP.
>>>>>>
>>>>>> Ele pedem para bloquearmos, a exemplo, o trafego que sai através 
>>>>>> de uma
>>>>>> porta X.
>>>>>>
>>>>>>
>>>>>> Bem, devemos sempre colaborar...
>>>>>>
>>>>>>
>>>>>> Tenho equipamentos Cisco e Mikrotik. O que vocês recomendam?
>>>>>>
>>>>>>
>>>>>> Configurar um Firewall Foward no Router BGP, nos Concentradores 
>>>>>> PPPoE?
>>>> Se
>>>>>> eu subir um FIREWALL eu vou ter um aumento considerável no 
>>>>>> processamento
>>>>>> dos meus equipamentos.  😖  :(
>>>>>>
>>>>>>
>>>>>> Realmente gostaria de ler a experiência de vocês. Agradeço a quem me
>>>>>> ajudar.
>>>>>>
>>>>>>
>>>>>> Att,
>>>>>>
>>>>>> Tárcio 