Pourquoi vpnc se déconnecte au bout de 24 minutes et quoi changer

Votre tunnel meurt à un intervalle reproductible, et c’est un minuteur qui se signale, pas un mauvais câble. Vingt-quatre minutes font 1440 secondes, le genre de valeur ronde que porte un profil ou une politique de tête de réseau. La même configuration échoue ensuite contre le même concentrateur à chaque fois alors que tout autre réseau fonctionne, et aucun test de liaison n’y change rien.

Trois conditions décident quel minuteur est le vôtre : si le client abandonne une session inactive, si l’échange de renouvellement de clés est refusé et si une passerelle de traduction a réécrit l’encapsulation.

Quel minuteur possède la coupure

Mesurez l’intervalle sur au moins trois reconnexions avant de toucher à un réglage. Une dispersion de quelques secondes indique une perte de liaison ou une itinérance sans fil ; une valeur qui tombe chaque fois à quelques secondes près du même repère indique une valeur de politique. La durée de la session indique aussi qui l’a terminée, car un délai côté client et une suppression côté serveur laissent des dernières lignes différentes dans la sortie de débogage. Trois reconnexions révèlent aussi si l’intervalle dérive, ce qu’une seule mesure ne peut pas montrer.

Notez le nombre à côté de la tête de réseau à laquelle vous parliez. Une fois l’intervalle stable, le travail restant consiste à choisir entre trois causes, et un seul réglage modifié par reconnexion est ce qui les garde distinguables.

Cas un : le client abandonne une session inactive

vpnc exécute sa propre vérification de pair mort, et cette vérification peut tuer une session que le concentrateur croit encore vivante, surtout lorsqu’une passerelle de traduction se trouve entre les deux. Le remède côté client dans la documentation est de couper le minuteur localement et de laisser la tête de réseau décider quand un pair a disparu. Les deux lignes ci-dessous vont dans le profil vpnc ou sur la ligne de commande, et toutes deux sont indépendantes des réglages de chiffrement.

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

Désactiver le DPD client supprime un faux positif et supprime aussi votre seule détection locale, alors appliquez-le seul et regardez si l’intervalle change du tout.

Cas deux : le renouvellement de clés est refusé

Si l’intervalle survit au changement de DPD, le renouvellement de clés de la phase 1 devient le candidat. Les anciennes versions de vpnc géraient le renouvellement avec moins de soin que les actuelles, et le groupe Diffie-Hellman est le désaccord habituel. Forcer un groupe que la tête de réseau accepte déjà coûte une ligne et une reconnexion, ce qui en fait une expérience bon marché plutôt qu’un changement de politique.

IKE DH Group dh5

Les noms de groupe valides sont dh1, dh2 et dh5. Un groupe que le concentrateur refuse produit un échec immédiat, et c’est encore une information : cela vous dit que la tête de réseau est exigeante et que le groupe d’origine était probablement correct.

Cas trois : la traduction réécrit l’encapsulation

Derrière une passerelle de traduction, l’encapsulation UDP de Cisco et le mode fondé sur les standards ne sont pas interchangeables. Le mauvais choix produit souvent un tunnel qui s’établit, fait passer le trafic puis expire sous charge, ce qui se lit comme un problème de bande passante et n’en est pas un. Changez seulement le mode, puis reconnectez-vous et chronométrez à nouveau la coupure. N’essayez l’autre mode qu’après avoir écarté les deux premiers cas.

Les interfaces ajoutent leur propre confusion ici. NetworkManager ne proposera pas de type de connexion vpnc tant que le paquet du greffon n’est pas installé, et un greffon manquant apparaît comme un bouton Ajouter grisé plutôt que comme une erreur. L’interface de KDE conserve les mêmes valeurs dans son propre profil, alors vérifiez que le démon lit ce que vous avez modifié.

Un profil qui se connecte bien depuis la ligne de commande mais pas depuis le bureau est un problème d’interface, pas un problème de minuteur.

Vérifiez l’échange qui échoue avant le troisième changement

Lancez le client avec la sortie de débogage et lisez le dernier échange avant la coupure. Une suppression de phase 1 juste avant la déconnexion signifie que le client a renouvelé les clés et a été refusé. Une suppression de phase 2 au même point signifie que le tunnel a été démonté de l’autre côté, et que vos réglages client ne sont pas la cause.

vpnc --debug 3 office

Vérifiez aussi la présence d’un second démon réseau lorsque le tunnel survit mais que le trafic s’arrête. Deux gestionnaires qui écrivent la table de routage produisent le même symptôme depuis le bureau et un journal complètement différent.