[GTER] CGNAT em Mikrotik - Tempo de TCP Established Timeout

[Andre Almeida]

Joia, eu vou ampliar pra 3h então, isso que eu gostaria de saber... se
havia um cenário "boa prática"
Aqui também já temos IPv6 também.

Digo pré determinístico pois já vi gente usar com log de portas, fazendo
com que haja a escolha aleatória das portas.

Eu uso o cenário com netmap, poucas regras e apenas uma planilha
relacionando as portas com os blocos privados/públicos já garantem a
relação.


Em sex., 22 de jan. de 2021 às 19:11, Fernando Frediani <
fhfrediani at gmail.com> escreveu:

> Olá Andre
>
> Vou na mesma linha que você.  Creio que se é necessário utilizar CGNAT
> isso tem que ser feito de maneira adequada para que o a técnica funcione
> adequadamente e com eficiência para aquele ambiente.
>
> Porém mesmo que esse tipo de tráfego seja menor em um ambiente
> residencial existem cada vez mais pessoas (profissionais de TI
> principalmente) que trabalham em regime de home-office e se for possível
> por que não evitar criar dificuldades pra eles (nós) também ?
>
> Aqui nas implementações que fiz utilizo o valor de 3 horas para o TCP
> Estabilished Timeout. Tem parecido bastante adequado e nunca chegou a
> ter situações de exaurimento de portas. Porém nunca é demais lembrar a
> condição para isso que é ter IPv6 disponível na mesma conexão.
>
> Eu só fiquei em dúvida sobre o que você quis dizer com "pré
> determinístico". Para Mikrotik com a possibilidade de identificar o
> usuário de maneira única eu só conheço a possibilidade de fazer com
> determinístico (intervalo de portas fixo por IP de CGNAT).
>
> Fernando Frediani
>
> On 22/01/2021 18:54, Andre Almeida wrote:
> > Qual seria o outro lado da moeda em deixar com o padrão de 24h que vem ?
> > Acredito que deixar conexões que já não possuem tráfego há muito
> > tempo, ali, mapeadas, apenas levando em considerações pequenos
> > tráfegos de:
> >
> > SSH, Telnet ou FTP
> >
> > que convenhamos, são bem raros em clientes residenciais ( que
> > justamente são os que são o foco do CGNAT )
> > tem que ver o que seria o melhor benefício... segurar as portas
> > considerando casos raríssimos ou então liberá-las para um maior
> > rodízio.
> >
> > Esse é o meu entendimento...
> > Não sei se estou equivocado nas minhas colocações
> >
> >
> >
> > Em sex., 22 de jan. de 2021 às 18:26, Douglas Fischer
> > <fischerdouglas at gmail.com> escreveu:
> >> Tá falando do "TCP Established Timeout"?
> >>
> >> Se sim, 15 minutos é um tempo pequeno demais!
> >>
> >> Isso significa por exemplo que:
> >>   - Se o cara tiver um serviço de FTP que se conecta na porta 21, e
> >> sob-demanda(ainda na mesma conexão) ele só envie e receba comandos... A
> >> cada 15 minutos a conexão dele faz seer dropada pelor seu CGNAT.
> >>   - Se o cara fizer uma conexão SSH ou Telnet para fora, e passar mais
> de 15
> >> minutos sem alguma interação, a conexão dele vai ser dropada pelo seu
> CGNAT.
> >>   - Se o cara tiver uma aplicação que de dentro da rede dele faça uma
> TCP
> >> qualquer para um destino externo, e mante alguma atualização para esse
> >> destino a cada 1 hora mantendo a mesma conexão TCP, toda vez que a
> >> aplicação dele for tentar mandar alguma coisa, a conexão vai estar
> quebrada.
> >>
> >>
> >> Se você fosse cliente de um provedor que te impusesse essas
> >> características, você ficaria feliz?
> >>
> >>
> >>
> >> Em sex., 22 de jan. de 2021 às 17:17, Andre Almeida <andre at bnet.com.br>
> >> escreveu:
> >>
> >>> Amigos, boa tarde!
> >>>
> >>> Alguem sabe qual a boa prática pra CGNAT  no tempo do TCP Established
> >>> Timeout?
> >>>
> >>> Estou usando 15 minutos aqui e estou tendo um resultado legal...
> >>> Estou usando CGNAT pré determinístico e com um bom range de portas pra
> >>> cada IP de CGNAT ( em torno de 5 mil )
> >>> .
> >>> Pelo que eu entendo, ele ajudaria a diminuir novos handshakes, seria
> isso?
> >>> E também aumentaria o uso a mais devices, não segurando a porta por
> >>> muito tempo ali na tabela caso a conexão já esteja sem tráfego.
> >>>
> >>> Agradeço comentários!
> >>>
> >>> Andre
> >>> --
> >>> 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
>