Soluções alternativas para provável problema de TIME_WAIT impedindo o restabelecimento de túneis SSH quebrados?

Question

Embora não tenha a intenção de enviar mensagens cruzadas, depois de enviar essa pergunta para a lista do OpenSSH no SecurityFocus, notei que a lista tem um tráfego muito baixo (a postagem anterior foi aproximadamente cinco meses antes). Dito isso, decidi repassar aqui, pois a questão provavelmente terá mais olhos (e terá uma chance maior de ser útil para os outros se for respondida):

O problema: Eu tenho um túnel SSH reverso de uma máquina interna para um host na minha DMZ que está configurado para iniciar na inicialização do sistema e relançar se o túnel falhar. No entanto, quando o túnel é interrompido (por exemplo, devido a uma interrupção da rede), ele não pode ser restabelecido devido à porta no host DMZ estar em uso. Da minha leitura dos arquivos da lista de discussão do OpenSSH e em outros lugares, isso parece ser porque a porta está em um estado TIME_WAIT. Isso é bom: eu posso colocar uma declaração de suspensão no script que configura o túnel. No entanto, isso leva a duas questões:

1) Alguma idéia de como determinar o que o intervalo TIME_WAIT é definido como em um determinado sistema Linux (ou outro)? Enquanto eu poderia apenas dormir por 5 minutos e ficar bem, seria bom fazer o maior tempo possível. 2) Embora o OpenSSH não apóie a opção "ClearAllForwardings", existe uma funcionalidade similar na qual uma conexão authd pode desmontar e recriar automaticamente uma conexão já estabelecida anteriormente?

Um longo sono provavelmente seria "bom o suficiente", mas eu preferiria lidar com a condição TIME_WAIT de maneira mais eficiente, se possível.

Agradeço qualquer orientação ou sugestão!     

Answer 1

Eu acho que você poderia jogar com várias configurações de SSH, como TCPKeepAlive, ServerAliveInterval, ServerAliveCountMax, etc, para configurar onde, se a conexão cair, isso matará tudo. Eu tenho uma configuração semelhante e tenho feito muitas modificações para ambos SSHD e SSH em ambos os lados para combinar com o que eu quero. Então eu tenho um cron job que executa a cada 5 min que reinicia o túnel, se eu precisar.

#!/bin/bash
if ps aux | grep "ssh -fnNTx" | grep -v "grep"
then
echo "Already Running"
else
echo "Starting now"
ssh -fnNTx -L 1514:127.0.0.1:514 [email protected]
fi

Até agora, esta solução funcionou bem para mim. Você também pode configurar algum tipo de verificação do Nagios ou outro script para ver se o túnel está aberto e se não, faça um kill desse pid para que ele possa ser reiniciado.

Editar:

Artigo anterior que fala muito sobre os problemas de TIME_WAIT. Como fechar forçosamente um soquete em TIME_WAIT?

    

Answer 2

O SSHD deve definir SO_REUSEADDR, permitindo que a nova instância seja vinculada mesmo que a instância anterior ainda tenha conexões no estado TIME_WAIT. Ou você tem um SSHD com bugs ou você tem alguma configuração que inibe esse comportamento (por exemplo, se você desabilitou o X11UseLocalHost ).