tempo de conexão SSH em determinados clientes apenas

1

Eu tenho um servidor com cerca de 100 conexões de túnel SSH ativas de servidores clientes no Canadá e nos EUA. Usamos o mesmo dispositivo que executa uma compilação personalizada do Ubuntu e carregamos isso em cada servidor cliente que se conecta ao servidor. Recentemente, tentei configurar alguns desses servidores clientes e estou recebendo um tempo limite de conexão ao tentar conectar-me ao servidor principal a partir desses servidores cliente.

Aqui estão alguns dos passos importantes de depuração que tomei e seus resultados:

  1. O servidor do cliente está recebendo um tempo limite ao tentar se conectar ao servidor principal, mesmo que ele possa efetuar ping no servidor.
  2. Ao tentar fazer telnet na porta 22, a conexão expira ao invés de receber o reconhecimento de SSH
  3. Eu posso SSH em qualquer outra máquina desse servidor cliente, exceto o servidor principal
  4. Outras máquinas podem executar o SSH no servidor principal, mesmo no mesmo endereço IP dos servidores do cliente
  5. Cada servidor do cliente tem a mesma configuração do SO que os outros servidores do cliente
  6. Existem cerca de 100 conexões ativas de outros servidores clientes atualmente implantados usando a mesma configuração, mas somente esses novos estão enfrentando o problema
  7. Eu aumentei o número máximo de tentativas de conexão SSH (MaxStartups) bem como o número máximo de conexões de soquete TCP (net.core.somaxconn) para 2000 e 65535, respectivamente, e isso não melhorou a situação

Estou preso e preciso descobrir por que isso está acontecendo. Qualquer ajuda seria apreciada. Obrigado!

    
por TopDogg25 21.07.2014 / 19:26

1 resposta

3

Depois de muita investigação e pesquisas no Google, consegui encontrar a causa raiz e, finalmente, uma correção. Depois de excluir problemas de rede e DNS, só fiquei com o protocolo. Como o Ping funcionava e o telnet para a porta 1 não, eu sabia que não poderia ser um problema de porta. Depois de testar o tráfego com UDP e TCP, descobriu-se que o TCP era o único protocolo que estava tendo o problema.

Corri tcpdump para verificar os pacotes que estavam sendo trocados e notei imediatamente que apenas o pacote SYN inicial estava sendo enviado do cliente para o servidor e o ACK não estava sendo retornado. Infelizmente, ainda não foi encontrada nenhuma causa raiz.

Ao executar netstat -s antes e depois de tentar várias conexões ssh em algumas tentativas, o único valor que estava desativado foi a "Conexão passiva rejeitada por causa do registro de data e hora". Eu encontrei este artigo (em japonês) que estava relacionado a esse problema e sugeriu uma relação com o tcp_tw_recycle em um ambiente NAT. A conclusão resultante foi desabilitar tcp_tw_recycle, a conseqüência é que o número de conexões TCP abertas dobrou, nós conseguimos resolver o problema. Esta resposta do ServerFault discute são ramificações em detalhes.

Espero que esta resposta seja útil para alguém que acabe lidando com esse caso extremo. Além disso, alguém tem alguma sugestão / aviso adicional relacionado a esta solução?

    
por 22.07.2014 / 22:37