Reconectar um túnel SSH SOCKS com autossh
Use autossh com verificações de vitalidade SSH e entenda que reconectar um túnel não restaura as ligações antigas das aplicações.
Um proxy SSH SOCKS desaparece quando a sua ligação SSH termina. Um supervisor pode reiniciar essa ligação, mas não pode retomar cada pedido de site que usava o fluxo antigo.
Para uma configuração SSH que já funciona, o autossh pode supervisionar um encaminhamento dinâmico enquanto o OpenSSH deteta um servidor que não responde:
autossh -M 0 -N -o ServerAliveInterval=30 -o ServerAliveCountMax=3 -o ExitOnForwardFailure=yes -D 127.0.0.1:1080 [email protected]-M 0 desativa o mecanismo separado de porta de monitorização do autossh. Baseia-se na saída do SSH para que o supervisor possa reagir. As opções server-alive fornecem uma verificação de vitalidade ao nível do SSH; não pedem uma página a cada destino que utiliza.
Mantenha a configuração inicial visível até a autenticação e o encaminhamento funcionarem. O comportamento em segundo plano do autossh difere do -f do SSH simples: um arranque sem supervisão não pode parar para pedir uma palavra-passe ou frase de chave. A sua porta de arranque documentada também pode distinguir uma falha imediata de configuração de uma sessão quebrada mais tarde.
Após a reconexão, o ouvinte local pode voltar a estar disponível. As aplicações podem ainda precisar de repetir as suas próprias operações falhadas. Um carregamento interrompido antes de receber uma resposta tem um resultado ao nível da aplicação a resolver, não apenas um túnel em falta para reiniciar.
Por fim, um transporte SSH saudável não prova que a porta de ligação consiga alcançar um determinado site. Separe a supervisão do túnel da monitorização da tarefa que o utiliza.