Quais são as ramificações da configuração de tcp_tw_recycle / reuse para 1?

Question

Eu configurei ambos tcp_tw_recycle / reuse para 1 no meu arquivo de configuração.

Quais são as ramificações disso?

Se um soquete TCP for reutilizado, isso representa um risco de segurança? Ou seja, 2 conexões diferentes, sendo potencialmente capazes de enviar dados?

É adequado para conexões de curta duração com pouca chance de reconexão?

    

Answer 1

Por padrão, quando ambos tcp_tw_reuse e tcp_tw_recycle estão desabilitados, o kernel se certificará de que os sockets em TIME_WAIT state permanecerão nesse estado por tempo suficiente - tempo suficiente para garantir que os pacotes pertencentes a futuras conexões não será confundido com pacotes atrasados da conexão antiga.

Quando você ativa tcp_tw_reuse , os sockets em TIME_WAIT state podem ser usados antes de expirarem, e o kernel tentará certificar-se de que não haja colisão em relação aos números de seqüência do TCP. Se você habilitar tcp_timestamps (a.k.a. PAWS, para Proteção Contra Números de Seqüência Envolvidos), ele fará com que essas colisões não aconteçam. No entanto, você precisa que os timestamps TCP sejam ativados em ambos (pelo menos, esse é o meu entendimento). Veja a definição de tcp_twsk_unique para detalhes sangrentos.

Quando você ativa tcp_tw_recycle , o kernel se torna muito mais agressivo e faz suposições sobre os timestamps usados pelos hosts remotos. Ele rastreará o último registro de data e hora usado por cada host remoto com uma conexão em TIME_WAIT state) e permitirá a reutilização de um soquete se o registro de data e hora tiver aumentado corretamente. No entanto, se o registro de data e hora usado pelo host for alterado (ou seja, de volta no tempo), o pacote SYN será silenciosamente descartado e a conexão não será estabelecida (você verá um erro semelhante a "tempo limite de conexão"). Se você quiser mergulhar no código do kernel, a definição de tcp_timewait_state_process pode ser um bom ponto de partida.

Agora, os timestamps nunca devem voltar no tempo; a menos que:

• o host é reinicializado (mas, quando ele voltar, TIME_WAIT socket provavelmente terá expirado, portanto, não será um problema);
• o endereço IP é reutilizado rapidamente por outra coisa ( TIME_WAIT conexões ficarão um pouco, mas outras conexões provavelmente serão atingidas por TCP RST e isso liberará algum espaço);
• A tradução de endereços de rede (ou um firewall inteligente) está envolvida no meio da conexão.

No último caso, você pode ter vários hosts atrás do mesmo endereço IP e, portanto, sequências diferentes de registros de data e hora (ou, esses registros de tempo são randomizados em cada conexão pelo firewall). Nesse caso, alguns hosts serão aleatoriamente incapazes de se conectar, porque eles são mapeados para uma porta para a qual o intervalo TIME_WAIT do servidor possui um registro de data e hora mais recente. É por isso que os documentos informam que "os dispositivos NAT ou os balanceadores de carga podem começar a eliminar quadros devido à configuração".

Algumas pessoas recomendam a deixar apenas tcp_tw_recycle , mas ativar tcp_tw_reuse e diminuir tcp_timewait_len . Eu concordo: -)

    

Answer 2

Eu só tinha isso me morder, então talvez alguém possa se beneficiar da minha dor e sofrimento. Primeiro, um link envolvido com muitas informações: link

Em particular:

The mere result of this lack of documentation is that we find numerous tuning guides advising to set both these settings to 1 to reduce the number of entries in the TIME-WAIT state. However, as stated by tcp(7) manual page, the net.ipv4.tcp_tw_recycle option is quite problematic for public-facing servers as it won’t handle connections from two different computers behind the same NAT device, which is a problem hard to detect and waiting to bite you:

Eu usei aqueles habilitados com bastante sucesso para fornecer a menor latência possível, conectividade haproxy de clientes para um cluster MySql NDB. Isto estava em uma nuvem privada, e nenhuma conexão de qualquer para qualquer tinha qualquer tipo de NAT na mistura. O caso de uso fazia sentido, diminuir a latência de clientes radius que acessam o NDB via haproxy tanto quanto humanamente possível. Isso aconteceu.

Eu fiz isso novamente em um sistema haproxy voltado ao público, balanceando a carga do tráfego da web, sem realmente estudar o impacto (estúpido, certo ?!) e descobri depois de muita solução de problemas e perseguindo fantasmas que:

• Ele criará caos para os clientes que se conectarem por meio de um NAT.
• É quase impossível identificar porque é completamente aleatório, intermitente, e os sintomas atingirão o cliente A, em tempos completamente diferentes (ou não) do que o cliente B, etc.

No lado do cliente, eles verão períodos de tempo em que não receberão mais respostas aos pacotes SYN, às vezes aqui e ali, e às vezes por longos períodos. Mais uma vez, aleatório.

O conto aqui, na minha recente e dolorosa experiência, é deixar estes sozinhos / desativados em servidores públicos, independentemente do papel!

    

Answer 3

De 'man 7 tcp' Você verá isto:

   tcp_tw_recycle (Boolean; default: disabled; since Linux 2.4)
          Enable fast recycling of TIME_WAIT sockets.  Enabling this option is not recommended since this causes problems when working with NAT
          (Network Address Translation).

   tcp_tw_reuse (Boolean; default: disabled; since Linux 2.4.19/2.6)
          Allow  to  reuse  TIME_WAIT  sockets  for  new connections when it is safe from protocol viewpoint.  It should not be changed without
          advice/request of technical experts.

Não há muita ajuda lá. Esta questão também tem uma boa visão:

link

Mas não há informações específicas sobre por que a reutilização é mais segura do que a reciclagem. A resposta básica é que tcp_tw_reuse permitirá que se faça uso do mesmo socket se já houver um em TIME_WAIT com os mesmos parâmetros TCP e que esteja em um estado onde nenhum tráfego adicional é esperado (acredito que quando um FIN foi enviado ). O tcp_tw_recycle, por outro lado, apenas reutilizará os sockets que estão em TIME_WAIT com os mesmos parâmetros, independentemente do estado, o que pode confundir os firewalls com estado que podem estar esperando pacotes diferentes.

tcp_tw_reuse pode ser feito seletivamente no código, definindo a opção de soquete SO_REUSEADDR, documentada em man 7 socket como tal:

   SO_REUSEADDR
          Indicates that the rules used in validating addresses supplied in a bind(2) call should allow reuse of local addresses.  For  AF_INET
          sockets  this means that a socket may bind, except when there is an active listening socket bound to the address.  When the listening
          socket is bound to INADDR_ANY with a specific port then it is not possible to bind to this port for any local address.   Argument  is
          an integer boolean flag.