Por que o vpnc desconecta aos 24 minutos e o que mudar

O seu túnel morre num intervalo repetível, e isso é um temporizador que se denuncia, não um cabo defeituoso. Vinte e quatro minutos são 1440 segundos, o tipo de valor redondo que um perfil ou uma política do head-end carrega. Depois a mesma configuração falha contra o mesmo concentrador todas as vezes enquanto qualquer outra rede funciona, e nenhum teste de link muda isso.

Três condições decidem qual temporizador é o seu: se o cliente abandona uma sessão inativa, se a troca de renovação de chaves é recusada e se um gateway de tradução reescreveu o encapsulamento.

Qual temporizador é dono da queda

Meça o intervalo ao longo de pelo menos três reconexões antes de tocar num ajuste. Uma dispersão de segundos aponta para perda de link ou roaming sem fio; um valor que cai sempre dentro de alguns segundos da mesma marca aponta para um valor de política. A duração da sessão também diz quem a terminou, porque um tempo limite do lado do cliente e uma eliminação do lado do servidor deixam linhas finais diferentes na saída de depuração. Três reconexões também revelam se o intervalo deriva, algo que uma única medição não consegue mostrar.

Anote o número ao lado do head-end com quem estava a falar. Depois de o intervalo estar estável, o trabalho que resta é escolher entre três causas, e mudar um único ajuste por reconexão é o que as mantém distinguíveis.

Caso um: o cliente abandona uma sessão inativa

O vpnc executa a sua própria verificação de par morto, e essa verificação pode matar uma sessão que o concentrador ainda considera viva, sobretudo quando entre os dois está um gateway de tradução. A solução do lado do cliente na documentação é desligar o temporizador localmente e deixar o head-end decidir quando um par desapareceu. As duas linhas abaixo pertencem ao perfil do vpnc ou à linha de comandos, e ambas são independentes dos ajustes de cifra.

DPD idle timeout (our side) 0
NAT Traversal Mode cisco-udp

Desativar o DPD do cliente remove um falso positivo e também remove a sua única deteção local, por isso aplique-o sozinho e veja se o intervalo muda de todo.

Caso dois: a renovação de chaves é recusada

Se o intervalo sobreviver à mudança de DPD, a renovação de chaves da fase 1 passa a ser a candidata. As versões antigas do vpnc tratavam a renovação com menos cuidado do que as atuais, e o grupo Diffie-Hellman é a discordância habitual. Forçar um grupo que o head-end já aceita custa uma linha e uma reconexão, o que o torna uma experiência barata e não uma mudança de política.

IKE DH Group dh5

Os nomes de grupo válidos são dh1, dh2 e dh5. Um grupo que o concentrador recusa produz uma falha imediata, e isso ainda é informação: diz-lhe que o head-end é exigente e que o grupo original provavelmente estava correto.

Caso três: a tradução reescreve o encapsulamento

Atrás de um gateway de tradução, o encapsulamento UDP da Cisco e o modo baseado em padrões não são intercambiáveis. A escolha errada produz muitas vezes um túnel que se estabelece, passa tráfego e depois expira sob carga, o que se lê como um problema de largura de banda e não é. Mude apenas o modo, depois reconecte e cronometre a queda outra vez. Experimente o outro modo só depois de descartar os dois primeiros casos.

As interfaces acrescentam aqui a sua própria confusão. O NetworkManager não oferece um tipo de ligação vpnc enquanto o pacote do plugin não estiver instalado, e um plugin ausente aparece como um botão Adicionar cinzento em vez de um erro. A interface do KDE guarda os mesmos valores num perfil próprio, por isso confirme que o daemon lê o que editou.

Um perfil que liga bem a partir da linha de comandos mas não a partir do ambiente de trabalho é um problema de interface, não um problema de temporizador.

Verifique a troca que falha antes da terceira mudança

Execute o cliente com saída de depuração e leia a última troca antes da queda. Uma eliminação da fase 1 imediatamente antes da desconexão significa que o cliente renovou as chaves e foi recusado. Uma eliminação da fase 2 no mesmo ponto significa que o túnel foi desmontado do outro lado, e que os seus ajustes de cliente não são a causa.

vpnc --debug 3 office

Verifique também se há um segundo daemon de rede quando o túnel sobrevive mas o tráfego pára. Dois gestores que escrevem a tabela de rotas produzem o mesmo sintoma a partir do ambiente de trabalho e um registo completamente diferente.