Nenhuma resposta para alguns pacotes SYN quando os carimbos de data / hora estão ativados


9

Eu tenho um servidor TCP escutando em uma máquina ("o servidor") executando o Ubuntu 12.04.3 (kernel 3.8.0-31-genérico). Ele recebe conexões de 2 máquinas clientes diferentes. A máquina A está executando o Ubuntu 12.04.4 (3.11.0-17-genérico) e a máquina B está executando o Ubuntu 11.10 (3.0.0-32-server).

Se os carimbos de data / hora TCP estiverem ativados no servidor (sysctl net.ipv4.tcp_timestamps = 1), algumas vezes os pacotes SYN da máquina A serão "ignorados". Usando o tcpdump no servidor (no modo não promíscuo), vejo os SYNs chegarem OK e com somas de verificação corretas - simplesmente não há resposta - nenhum SYN / ACK e nenhum RST. A máquina A retransmite o SYN várias vezes antes de desistir. O software cliente em execução na máquina A (neste caso, wget) tenta novamente imediatamente com uma nova conexão e obtém êxito, obtendo um SYN / ACK instantâneo.

A máquina B não tem problemas com o mesmo servidor e seu tráfego parece normal - também está usando as mesmas opções de TCP da máquina A (pelo que vejo nos arquivos de captura). Desativar carimbos de data e hora TCP no servidor faz com que tudo funcione como deveria.

Os registros de data e hora nos pacotes SYN ignorados parecem ser válidos para mim, portanto, não tenho certeza por que eles estão causando problemas ou se são a causa subjacente.

Coloquei um pcap anonimizado aqui https://www.dropbox.com/s/onimdkbyx9lim70/server-machineA.pcap . Foi tirada no servidor (10.76.0.74), mostrando a máquina A (10.4.0.76) executando com êxito um HTTP GET (pacotes de 1 a 10) e, em seguida, 1 segundo depois, tentando buscar a mesma URL novamente (pacotes de 11 a 17), mas em vez disso tem seus SYNs ignorados. Os pacotes 18 a 27 são outro sucesso.

Suspeito que este seja um problema semelhante ao descrito em " Por que um servidor não enviaria um pacote SYN / ACK em resposta a um pacote SYN " e, ao desabilitar os carimbos de hora, é uma solução alternativa que eu gostaria de entender o que está acontecendo. Isso é apenas um bug?

Não há firewall local em execução. O servidor lida com várias conexões TCP (aproximadamente 32 K por vez), mas possui bastante memória / CPU livre. No momento do teste mostrado no pcap, não havia outras conexões TCP entre a máquina A e o servidor. Não há sinal de que a fila de aceitação do aplicativo de servidor esteja subitamente sendo preenchida (além disso, isso deve afetar os dois clientes que eu presumo). Como os pacotes parecem bons em um pcap obtido no servidor, não parece que um dispositivo de rede interveniente esteja quebrando as coisas.

Eu originalmente postei isso nos fóruns do ubuntu, mas, em retrospectiva, esse pode ser um local mais apropriado. Esperando o empréstimo de uma pista.

Respostas:


5

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

sysctl -w net.ipv4.tcp_tw_recycle=0

Eu acho que é mais correto do que desativar os registros de data e hora do TCP, pois os registros de data e hora do TCP são úteis (PAWS, redimensionamento de janelas, etc.).

A documentação tcp_tw_recycleafirma explicitamente que não é recomendável habilitá-lo, pois muitos roteadores NAT preservam os carimbos de data e hora e, portanto, o PAWS entra em ação , pois os carimbos de data e hora 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.

Todas as máquinas em questão foram atualizadas e acredito que o problema não está mais acontecendo, por isso não posso tentar isso agora. Nesse caso, não havia NAT envolvido entre o cliente e o servidor. Ainda parece suspeito como um bug para mim.
user133831
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.