Os clientes Linux não podem se conectar, servidor e problema de tamanho / registro de data / hora do Windows TCP

Question

Nós temos um problema que um número de clientes (todo o Linux do Ubuntu) às vezes não é capaz de se conectar a um servidor remoto através do SSH. Se o problema ocorrer, os clientes Windows não terão esse problema e poderão se conectar bem.

Eu encontrei essa outra pergunta com um problema semelhante: Por que um servidor não envia um pacote SYN / ACK em resposta a um pacote SYN

Desativar o Timestamping TCP no servidor realmente resolve o problema, mas eu gostaria de saber qual é o problema real. Eu realmente não vejo por que isso deve causar algum problema, definitivamente não ao estabelecer a conexão.

Ao usar o Wireshark, vejo que os clientes Windows usam um tamanho de janela de 8192, enquanto os clientes Linux usam um tamanho de janela de 29200. Os clientes Windows recebem um SYN_ACK, os clientes Linux não. É possível que esse tamanho de janela inicial mais alto seja responsável por não enviar o SYN_ACK pelo servidor? Não consigo encontrar uma explicação sensata sobre o motivo pelo qual isso poderia causar o problema dado, mas, como essa é a única diferença (visível para mim), ela parece ter essa aparência. Estou faltando alguma coisa?

*** EDIT Depois de mais pesquisas, pensamentos e um pouco de magia vodu, acho que poderia ter uma explicação plausível. É preciso algumas suposições e condições específicas para estar em vigor, mas eu acredito que isso possa ser possível nesta situação em particular.

Ambos os usuários estão por trás do mesmo dispositivo NAT (no nosso caso, um firewall Fortigate). Este firewall irá atribuir portas locais em sua interface externa / IP para cada conexão NAT. Se a porta já estiver em uso para outro usuário, ela será ignorada. Se a conexão for fechada, a porta será liberada e retornada ao pool NAT. Se essa porta é então atribuída ao outro usuário, mas o servidor ainda possui algum registro da conexão (TIME_WAIT, final FIN / ACK não recebido) e o timestamp do pacote é menor que o da conexão anterior, o pacote será silenciosamente desprezado.

Ok, há muito de se lá, mas ... - os dois usuários estão desenvolvendo no mesmo site, então eles estarão fazendo muitas conexões com o mesmo servidor remoto - o firewall (Fortigate) mantém aparentemente um contador seqüencial da porta NAT por IP de origem / destinationIP / destinationPort. Se os contadores de ambos os usuários estiverem próximos um do outro, as chances de tal "colisão" acontecer com duas conexões com esse servidor não são tão improváveis, dado que o IP de destino como porta é o mesmo. Isso explicaria porque o problema só ocorre esporadicamente.

O único problema com essa teoria é que não consigo encontrar nenhuma evidência disso acontecendo no lado do servidor. Não há nenhuma conexão travada em TIME_WAIT ou algo assim, e eu suponho que uma vez que eles desapareçam da saída do netstat, o servidor esqueceu-se deles.

Eu acredito que o Tamanho da Janela inicial não desempenha um papel nisso, então estou chamando a atenção para uma das listas de suspeitos.

    

Answer 1

Portanto, se os clientes do Windows não tiverem o problema, meu palpite é que eles não estão solicitando timestamps TCP enquanto os do Linux estão. Você pode verificar isso olhando novamente para as capturas do Wireshark de ambos os exemplos.

Para iniciar a solução de problemas da causa subjacente do problema de registro de data e hora, a primeira tarefa seria verificar se o cliente e o servidor estão sincronizados com os servidores NTP. Se eles tiverem apenas um relógio de funcionamento livre, pode muito bem ser a causa do problema. Por exemplo:

 # ntpq -p
 remote           refid      st t when poll reach   delay   offset  jitter
========================================================================
*utcnist2.colora .ACTS.           1 u   92 1024  377   50.242    2.041   1.847
+time-c.timefreq .ACTS.           1 u  623 1024  377   55.413   -1.781   0.418

Certifique-se de que pelo menos um tenha o asterisco na frente. Isso significa que está em sincronia. De qualquer forma, é estranho ver a sessão TCP parada no início. Seria de esperar que ele parasse depois que alguns pacotes com valores de timestamp tivessem sido trocados. Mais precisamente, quando o valor do timestamp de um pacote parece estar atrasado em relação ao pacote anterior.