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

Fri Jan 22 23:23:04 -03 2021

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