muitos timestamps TCP diferentes através do servidor de causa de dispositivo NAT para descartar pacotes (PAWS)

Question

Várias estações de trabalho atrás do lado do cliente do firewall Network Address Translation (NAT) estão enviando informações de timestamp no pacote TCP para o nosso servidor. Os pacotes de muitas estações de trabalho chegam com carimbos de tempo fora da seqüência atrás do dispositivo NAT. Quando chegam ao nosso servidor - em alguns casos na mesma porta - o servidor não consegue diferenciar esses pacotes de outros que chegam na mesma porta e do mesmo IP do cliente (o dispositivo NAT).

O servidor interpreta os pacotes com registros de tempo fora da seqüência como pertencentes a uma conexão que já foi concluída, e o pacote é então ignorado - mas, neste caso, não deveria ser. Teses são pacotes legítimos de estações de trabalho por trás do dispositivo NAT. Eliminar pacotes com valores de registro de data e hora antigos é um recurso de design do TCP chamado PAWS ( link , Proteger contra sequências envolvidas ) - o servidor simplesmente assume que o pacote é antigo e já lidou com a conexão.

Para contornar isso, desativamos as configurações de registro de data e hora em nossos servidores. MAS - qual é a melhor prática para esta situação? Todos os servidores devem ter suporte para registro de data e hora desativado? Ou todos os dispositivos NAT devem remover ou reescrever os valores de registro de data e hora? Ou?

    

Answer 1

A porta de origem é um recurso de identificação adicional à conexão TCP e não devem ser atribuídas duas conexões atrás do dispositivo NAT à mesma porta de origem - os clientes nunca interferirão nas conexões um do outro, a menos que recebam a mesma porta de origem dispositivo NAT incorreto.

O PAWS não deveria estar descartando os pacotes necessários, apenas duplicados de reenviados - a entrega fora do pedido não atualiza o piso do timestamp. O valor do tempo é copiado do último segmento em seqüência; um pacote com um número de seqüência mais alto (isto é, um que é necessário) deve sempre ter um timestamp mais alto do que um com um número de sequência mais baixo.

Se estiver na seqüência correta, mas tiver um timestamp mais baixo, então o cliente TCP está se comportando mal - e se por alguma estranheza o PAWS estiver descartando pacotes bons em seqüência, o cliente deverá reenviá-lo com um novo timestamp, se recuperando de quaisquer problemas causados pelo descarte.

Qual comportamento você está vendo que o levou a essa questão?

    

Answer 2

No meu caso, o seguinte comando corrigiu o problema com a falta de respostas SYN / ACK do servidor Linux:

sysctl -w net.ipv4.tcp_tw_recycle=0

Eu acho que é mais correto do que desabilitar timestamps TCP, pois os timestamps TCP são úteis afinal (PAWS, dimensionamento de janelas, etc).

A documentação sobre o tcp_tw_recycle declara explicitamente que não é recomendado habilitá-lo, já que muitos roteadores NAT preservam os timestamps e, portanto, o PAWS entra em ação, já que os timestamps do mesmo IP não são consistentes.

   tcp_tw_recycle (Boolean; default: disabled; since Linux 2.4)
          Enable fast recycling of TIME_WAIT sockets.  Enabling this
          option is not recommended for devices communicating with the
          general Internet or using NAT (Network Address Translation).
          Since some NAT gateways pass through IP timestamp values, one
          IP can appear to have non-increasing timestamps.  See RFC 1323
          (PAWS), RFC 6191.