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

Andre Almeida andre at bnet.com.br
Fri Jan 22 23:26:48 -03 2021 

Pô, show de bola, com RFC a coisa ficou top...
Elevou o nível da conversa.

Obrigado Vinicius!
Vamos seguir as recomendações da RFC

Valeu



Em sex., 22 de jan. de 2021 às 23:23, Vinicius Gruske Dorneles
<viniciusgruske at gmail.com> escreveu:
>
> [ERRATA]
> Boa noite,
>
> RFC 5382:
>
> REQ-5:  If a NAT cannot determine whether the endpoints of a TCP
>         connection are active, it MAY abandon the session if it has been
>         idle for some time.  In such cases, the value of the "established
>         connection idle-timeout" MUST NOT be less than 2 hours 4 minutes.
>         The value of the "transitory connection idle-timeout" MUST NOT be
>         less than 4 minutes.
>         a) The value of the NAT idle-timeouts MAY be configurable.
>
>
> Portanto, o mínimo recomendado é 2 horas e 4 minutos.
>
>
> Para o UDP também tem uma recomendação na RFC 4787:
>
>
> REQ-5:  A NAT UDP mapping timer MUST NOT expire in less than two
>         minutes, unless REQ-5a applies.
>
>         a) For specific destination ports in the well-known port range
>            (ports 0-1023), a NAT MAY have shorter UDP mapping timers that
>            are specific to the IANA-registered application running over
>            that specific destination port.
>
>         b) The value of the NAT UDP mapping timer MAY be configurable.
>
>         c) A default value of five minutes or more for the NAT UDP mapping
>            timer is RECOMMENDED.
>
>
> No Mikrotik, o padrão é 3 minutos. Está dentro do "MUST", mas não
> dentro do "RECOMMENDED".
>
>
> Em sex., 22 de jan. de 2021 às 19:21, Andre Almeida <andre at bnet.com.br>
> escreveu:
>
> > 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
> > >
> > --
> > 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