Como depurar o SSH “tempo limite de conexão”

Question

Estou recebendo um erro (às vezes) ao conectar do host1 ao host2

Errno::ETIMEDOUT: Connection timed out - connect(2)

TCP dump no host1 ao tentar se conectar (tcpdump -vv -i eth0 -s 0 'porta 22 e host host2'):

19:13:47.510774 IP (tos 0x0, ttl 64, id 44238, offset 0, flags [DF], proto TCP (6), length 60)
    host1.50274 > host2.ssh: Flags [S], cksum 0x1409 (correct), seq 2693070134, win 5840, options [mss 1460,sackOK,TS val 867914232 ecr 0,nop,wscale 7], length 0
19:13:50.508713 IP (tos 0x0, ttl 64, id 44239, offset 0, flags [DF], proto TCP (6), length 60)
    host1.50274 > host2.ssh: Flags [S], cksum 0x111b (correct), seq 2693070134, win 5840, options [mss 1460,sackOK,TS val 867914982 ecr 0,nop,wscale 7], length 0
19:13:56.508707 IP (tos 0x0, ttl 64, id 44240, offset 0, flags [DF], proto TCP (6), length 60)
    host1.50274 > host2.ssh: Flags [S], cksum 0x0b3f (correct), seq 2693070134, win 5840, options [mss 1460,sackOK,TS val 867916482 ecr 0,nop,wscale 7], length 0

No host2 ao mesmo tempo (tcpdump -vv -i eth0 -s 0 'porta 22 e host host1'):

19:13:47.510512 IP (tos 0x0, ttl 62, id 44238, offset 0, flags [DF], proto TCP (6), length 60)
    host1.50274 > host2.ssh: Flags [S], cksum 0x1409 (correct), seq 2693070134, win 5840, options [mss 1460,sackOK,TS val 867914232 ecr 0,nop,wscale 7], length 0
19:13:50.508453 IP (tos 0x0, ttl 62, id 44239, offset 0, flags [DF], proto TCP (6), length 60)
    host1.50274 > host2.ssh: Flags [S], cksum 0x111b (correct), seq 2693070134, win 5840, options [mss 1460,sackOK,TS val 867914982 ecr 0,nop,wscale 7], length 0
19:13:56.508447 IP (tos 0x0, ttl 62, id 44240, offset 0, flags [DF], proto TCP (6), length 60)
    host1.50274 > host2.ssh: Flags [S], cksum 0x0b3f (correct), seq 2693070134, win 5840, options [mss 1460,sackOK,TS val 867916482 ecr 0,nop,wscale 7], length 0

Onde pode estar o problema? Como posso depurar isso?

    

Answer 1

Sugiro testar a rede com 'ping -s 1450' (o -s altera o tamanho do pacote de sondagem, o mtr não parece ter uma opção semelhante). Se os primeiros pacotes forem bem-sucedidos, mas não os outros, geralmente é porque o problema está ligado ao tamanho do pacote (por exemplo, em um meio problemático como um link de rádio externo sob chuva strong), a taxa de perda pode ser quase nula pequenos pacotes e perto de 1 para pacotes grandes. E a maioria dos protocolos começa com pequenos pacotes de negociação e, em seguida, alterna para pacotes grandes.

Notei que você diz que o HTTP está bem, o que refutaria minha hipótese, mas não tenho outra ideia no momento.