Depurando conexões TCP "entupidas"

Question

Estou tendo problemas com uma conexão com a Internet que parece "congelar" aleatoriamente conexões tcp arbitrárias quando elas não são usadas há algum tempo. As conexões permanecem estabelecidas, mas nenhum dado está chegando.

Quando isso acontece, netstat ainda mostra o status da conexão como ESTABLISHED no computador local:

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name Timer
tcp        0     53 192.168.0.10:41129      173.255.235.238:143     ESTABLISHED 8219/gnutls-cli  on (79.31/13/0)

.. e o servidor remoto:

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name Timer
tcp        0      0 173.255.235.238:143     68.5.174.98:41129       ESTABLISHED 5303/imapd       off (0.00/0/0)

No entanto, parece que nenhum dado é transferido. Se eu executar strace no processo local e remoto, ambos mostram apenas uma sequência repetitiva de chamadas selecionadas (com fds diferentes, é claro), por exemplo,

select(6, [0 5], NULL, NULL, {0, 50000}) = 0 (Timeout)
select(6, [0 5], NULL, NULL, {0, 50000}) = 0 (Timeout)
select(6, [0 5], NULL, NULL, {0, 50000}) = 0 (Timeout)

A conexão com a Internet em geral não parece afetada, eu ainda posso estabelecer novas conexões para o mesmo serviço no mesmo servidor sem quaisquer problemas. No entanto, os aplicativos locais afetados parecem não estar cientes do problema e apenas interrompem.

Cerca de 10 minutos após a tentativa de transmissão no terminal local, a conexão no terminal remoto desaparece do netstat (não consegui encontrar nenhum estado intermediário), mas ainda permanece ESTABLISHED no final local.

Finalmente, depois de mais alguns minutos, o aplicativo local aborta com um tempo limite e também desaparece da saída local do netstat.

Quando olho para uma captura de pacotes dessa conexão no lado do cliente, há um longo (esperado) período de inatividade que parece acionar o problema, então o terminal local tenta transmitir alguns dados novamente, mas nunca recebe um ACK. Em vez disso, 15 retransmissões TCP saem, com intervalos aumentando de 0,3 segundos para 120 segundos. Nenhuma atividade é capturada depois disso.

Alguém tem uma sugestão de como eu poderia depurar isso ainda mais para descobrir onde está o problema e como corrigi-lo?

Adicional e / ou como uma solução temporária: existe alguma maneira de reduzir globalmente o tempo limite no cliente e / ou servidor para reduzir o tempo antes que o aplicativo local seja abortado?

    

Answer 1

Resumindo a partir do thread debian-user :

Esses sintomas são consistentes com algum dispositivo NAT instalado entre o cliente e o servidor e a queda de conexões inativas após 300 segundos.

Deve haver um dispositivo NAT em algum lugar na cadeia, porque a idéia do cliente de seu endereço IP (192.168.0.10) difere da que o servidor usa para enviar dados para o cliente (68.5.174.98). Além disso, a rede 192.168.x.y é reservada para uso local.

Uma solução alternativa é ativar o TCP keep-alive. Infelizmente, isso precisa ser configurado em cada programa separadamente (por exemplo, usando a opção ServerAliveInterval em ssh). No entanto, no Linux, a biblioteca libkeepalive pode ser usada com LD_PRELOAD para ativar a opção de soquete necessária, mesmo para programas que normalmente não suportam isso.

Para mim, uma solução melhor foi substituir o gateway de cabo Cisco DPC3825 responsável por um modem a cabo NetGear CMD31T e um gateway NetGear WGR614v9. O primeiro também faz NAT, mas não tem um tempo limite tão curto.