ServerAliveInterval do SSH por VPN: qual extremo envia a sonda?

A maioria dos conselhos para manter uma sessão SSH viva para em «acrescente ServerAliveInterval 30» e deixa de fora as partes úteis. A palavra-chave é um temporizador do lado do cliente que só dispara quando o canal está silencioso, ele conta sondas sem resposta em vez de segundos, e vive num ficheiro onde o primeiro valor correspondente vence. Erre nestas três propriedades e uma sessão VPN saudável cai mesmo assim, enquanto uma morta fica pendurada.

As duas direções pertencem a daemons diferentes

ServerAliveInterval é lido pelo seu cliente ssh. ClientAliveInterval é lido pelo sshd do outro lado e sonda na direção oposta, do servidor para o cliente. Não são alias nem cooperam, portanto configurar um não tem efeito no comportamento do outro extremo. Confundi-los é a razão habitual para uma correção parecer funcionar num anfitrião e não no seguinte.

Ambos aceitam zero. Com zero o cliente não envia absolutamente nada, e do lado do servidor um ClientAliveCountMax de zero desativa a desconexão que de outro modo se seguiria às verificações sem resposta.

O que uma sonda prova e o que não prova

Depois de passar o intervalo configurado sem que cheguem dados do servidor, o cliente envia um pequeno pedido pelo canal cifrado existente e espera uma resposta. ServerAliveCountMax define quantas delas podem ficar sem resposta antes de a sessão ser derrubada. Com um intervalo de 60 e uma contagem de 3 o cliente desiste após cerca de três minutos de silêncio, e esse número é uma propriedade da sua configuração, não um padrão de rede. Deixe o intervalo no valor predefinido 0 e nenhuma sonda chega a ser enviada, e é por isso que um cliente comum pode ficar indefinidamente numa ligação morta.

Como a troca corre dentro do transporte SSH, uma resposta prova que o processo SSH do outro lado ainda lê e escreve. Não diz nada sobre o programa que iniciou dentro dessa sessão: um cliente de base de dados, uma porta reencaminhada ou um script de longa duração podem estar bloqueados enquanto o transporte responde alegremente às sondas.

TCPKeepAlive é um mecanismo separado uma camada abaixo. É tratado pelo kernel, não é cifrado, e um extremo cujo daemon SSH está bloqueado ainda o pode satisfazer. Por isso a sonda ao nível do SSH é o sinal mais significativo quando lhe importa a sessão e não o socket.

A ordem decide qual valor sobrevive

O OpenSSH aplica o primeiro valor que obtém para cada parâmetro, pelo que um bloco Host específico tem de aparecer antes de qualquer bloco mais amplo que também corresponda. Coloque os valores predefinidos com carateres universais no fundo do ficheiro, não no topo, e lembre-se de que um bloco Match mais abaixo não pode anular um valor já definido. A referência de configuração do cliente OpenSSH enuncia diretamente a regra do primeiro valor, e vale a pena lê-la uma vez antes de reorganizar uma configuração partilhada.

As opções de linha de comandos vencem o ficheiro, o que torna barato um ensaio temporário:

ssh -o ServerAliveInterval=15 -o ServerAliveCountMax=4 office-shell

Para ver o que o cliente resolveu realmente em vez do que pensa que escreveu, peça-lhe que despeje a configuração efetiva. A saída contém os valores fundidos para esse nome de anfitrião e é a forma mais rápida de apanhar um bloco anterior extraviado:

ssh -G office-shell | grep -i alive

O que os keepalives fazem por um túnel

O tráfego periódico impede que um mapeamento NAT ou de firewall com estado expire, o que é um benefício real numa VPN cujo gateway descarta os fluxos inativos ao fim de alguns minutos. As sondas que chegam a cada 60 segundos renovam esse mapeamento sem transportar quaisquer dados de aplicação.

Não conseguem reconstruir um caminho que desapareceu. Quando a interface do túnel desaparece as sondas falham como tudo o resto, e a sessão termina assim que a contagem se esgota. A deteção de vida e a recuperação do caminho são problemas diferentes, e só a primeira é configurável em ssh_config. O que o intervalo e a contagem realmente lhe compram é a rapidez com que o cliente percebe, e é essa a parte que o utilizador sente como um bloqueio.

As ligações multiplexadas acrescentam uma dobra. Com o ControlMaster em jogo, as sondas pertencem à ligação principal, e uma sessão nova sobre uma principal existente herda o que essa principal negociou. Se a principal do mux estiver bloqueada, abrir outra janela não voltará a testar o caminho.

Confirmar a configuração de ponta a ponta

No servidor, despeje a configuração efetiva do daemon em vez de ler o ficheiro e adivinhar qual include venceu:

sshd -T | grep -i clientalive

Depois observe uma sessão real com a saída de depuração ativada. O cliente imprime uma linha de tempo limite quando a contagem se esgota, e os carimbos de tempo à volta mostram se o silêncio foi contínuo ou se as sondas nunca chegaram a ser enviadas. Uma sessão que morre sem tráfego de sondas tem normalmente a palavra-chave num bloco que nunca correspondeu.

Vale a pena acrescentar duas verificações a qualquer anfitrião a que só chega por um túnel: confirme que o intervalo resolvido é o que pretendia, e confirme que esse intervalo multiplicado pela contagem é mais curto do que o tempo de inatividade no gateway da VPN. Quando o segundo número é maior, o gateway descarta primeiro o fluxo em silêncio e a sonda SSH nunca tem oportunidade de relatar nada.