Por que vpnc desconecta aos 24 minutos e que cambiar

O teu túnel morre nun intervalo repetible, e iso é un temporizador que se delata, non un cable defectuoso. Vinte e catro minutos son 1440 segundos, o tipo de valor redondo que leva un perfil ou unha política do head-end. Despois a mesma configuración falla contra o mesmo concentrador cada vez mentres calquera outra rede funciona, e ningunha proba de ligazón o cambia.

Tres condicións deciden cal temporizador é o teu: se o cliente abandona unha sesión inactiva, se se rexeita o intercambio de renovación de claves e se unha pasarela de tradución reescribiu a encapsulación.

Que temporizador é dono da caída

Mide o intervalo ao longo de polo menos tres reconexións antes de tocar un axuste. Unha dispersión de segundos apunta a perda de ligazón ou a itinerancia sen fíos; un valor que cae cada vez dentro duns segundos da mesma marca apunta a un valor de política. A duración da sesión tamén di quen a rematou, porque un tempo de espera do lado do cliente e un borrado do lado do servidor deixan liñas finais distintas na saída de depuración. Tres reconexións tamén revelan se o intervalo deriva, algo que unha soa medición non pode amosar.

Anota o número xunto ao head-end co que falabas. Unha vez que o intervalo é estable, o traballo restante é escoller entre tres causas, e cambiar un só axuste por reconexión é o que as mantén distinguibles.

Caso un: o cliente abandona unha sesión inactiva

vpnc executa a súa propia comprobación de par morto, e esa comprobación pode matar unha sesión que o concentrador aínda cre vivo, sobre todo cando entre os dous hai unha pasarela de tradución. O remedio do lado do cliente na documentación é apagar o temporizador localmente e deixar que o head-end decida cando un par se foi. As dúas liñas de abaixo van no perfil de vpnc ou na liña de ordes, e ambas son independentes dos axustes de cifrado.

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

Desactivar o DPD do cliente elimina un falso positivo e tamén elimina a túa única detección local, así que aplícao só e observa se o intervalo cambia de todo.

Caso dous: rexéitase a renovación de claves

Se o intervalo sobrevive ao cambio de DPD, a renovación de claves da fase 1 pasa a ser a candidata. As versións antigas de vpnc trataban a renovación con menos coidado que as actuais, e o grupo Diffie-Hellman é a discrepancia habitual. Forzar un grupo que o head-end xa acepta custa unha liña e unha reconexión, o que o converte nun experimento barato e non nun cambio de política.

IKE DH Group dh5

Os nomes de grupo válidos son dh1, dh2 e dh5. Un grupo que o concentrador rexeita produce un fallo inmediato, e iso segue sendo información: diche que o head-end é esixente e que o grupo orixinal probablemente era correcto.

Caso tres: a tradución reescribe a encapsulación

Detrás dunha pasarela de tradución, a encapsulación UDP de Cisco e o modo baseado en estándares non son intercambiables. A elección equivocada produce a miúdo un túnel que se establece, pasa tráfico e despois expira baixo carga, o que se le como un problema de ancho de banda e non o é. Cambia só o modo, despois reconecta e volve cronometrar a caída. Proba o outro modo só despois de descartar os dous primeiros casos.

As interfaces engaden aquí a súa propia confusión. NetworkManager non ofrecerá un tipo de conexión vpnc ata que estea instalado o paquete do complemento, e un complemento ausente aparece como un botón Engadir en gris en lugar dun erro. A interface de KDE garda os mesmos valores nun perfil propio, así que confirma que o demonio le o que ediches.

Un perfil que se conecta ben desde a liña de ordes pero non desde o escritorio é un problema de interface, non un problema de temporizador.

Verifica o intercambio que falla antes do terceiro cambio

Executa o cliente con saída de depuración e le o último intercambio antes da caída. Un borrado de fase 1 xusto antes da desconexión significa que o cliente renovou as claves e rexeitóuselle. Un borrado de fase 2 no mesmo punto significa que o túnel se desmontou desde o outro lado, e que os teus axustes de cliente non son a causa.

vpnc --debug 3 office

Comproba tamén se hai un segundo demonio de rede cando o túnel sobrevive pero o tráfico se detén. Dous xestores que escriben a táboa de rutas producen o mesmo síntoma desde o escritorio e un rexistro completamente distinto.