VPN reconnecté, mais la session de l’application échoue toujours

Le tunnel revient, le client annonce qu’il est connecté, et le navigateur tourne encore sur une page qu’il chargeait avant la coupure. Une reconnexion VPN restaure un chemin et ne restaure pas l’état de connexion que les applications et le côté distant ont accumulé sur l’ancien. Ce sont deux choses différentes à réparer, et les confondre vous renvoie dans les réglages du VPN sans raison.

Un test les sépare proprement, et il prend dix secondes. Envoyez une nouvelle requête vers la même destination pendant que l’ancienne reste bloquée.

Ce qui survit à une reconnexion et ce qui n’y survit pas

Un tunnel est un ensemble de routes, de clés et d’adresses, et une reconnexion peut restaurer les trois tandis que chaque flux établi reste mort. Le système d’exploitation garde un socket ouvert parce que l’application l’a demandé, et le délai d’expiration de ce socket peut être à des minutes ou des heures. En dessous, le pair a oublié le flux, une entrée de traduction a expiré, ou le chemin passe désormais par un point de terminaison qui n’a jamais vu la poignée de main. Rien dans la séquence de reconnexion ne parcourt les sockets de l’application pour les réparer.

Certains clients ajoutent un crochet qui supprime les connexions périmées à la reconnexion, et la plupart ne le font pas. Le comportement ici varie selon le client, la plateforme et la version.

Le côté distant vous a oublié aussi

L’extrémité distante garde son propre état : une session TLS, un bloc de contrôle TCP et peut-être une entrée de mappage qui lie votre adresse et votre port au flux. Un dispositif de traduction sur le chemin peut faire expirer ce mappage pendant l’interruption, même si le tunnel se rétablit vite. Une fois le mappage disparu, des paquets arrivent pour un flux que le serveur ne reconnaît plus, et la réponse peut être un reset que le client n’affiche jamais. Les applications signalent cela comme un blocage et non comme une erreur, parce qu’elles attendent encore un socket qui ne répondra jamais.

Les délais d’inactivité côté serveur font la même chose selon leur propre calendrier, ce qui explique qu’une session puisse mourir sans aucun événement réseau. Une connexion restée inactive plus longtemps que le serveur ne l’attend a déjà disparu avant que vous ne remarquiez que le tunnel a bougé.

Une requête neuve est le test qui les sépare

Envoyez une nouvelle requête vers le même hôte pendant que l’ancienne reste bloquée, et observez les deux. Si la nouvelle requête réussit, alors le tunnel, la route et la résolution de noms fonctionnent, et la panne se limite au flux périmé. Si la nouvelle requête échoue aussi, vous avez un problème de chemin et l’état de session de l’application est une fausse piste.

Laissez en place tout blocage du trafic direct pendant le test. Une requête qui réussit par un chemin de secours accidentel ne prouve rien sur le tunnel.

Confirmez avec une nouvelle connexion, pas avec l’ancienne

Les commandes ci-dessous montrent les sockets encore ouverts, lancent une nouvelle requête et vérifient si la table des sessions contient encore une entrée pour le flux. Exécutez la première avant et après la reconnexion pour que la différence soit visible. Remplacez l’hôte et le port par votre propre service.

ss -tanp | grep -E ':(443|8443)'
curl -sS -o /dev/null -w '%{http_code} %{time_connect}\n' --max-time 8 https://intranet.example.com/
conntrack -L 2>/dev/null | grep 8443
dig +short intranet.example.com

Un socket établi sans trafic qui circule est la signature à rechercher, et une nouvelle requête qui renvoie un code de statut montre que le chemin est vivant. La table des connexions répond si quelque chose mappe encore le flux, et c’est la partie que le client ne peut pas voir. La requête au résolveur couvre l’autre moitié du chargement d’une page, car un échec de nom et une connexion figée se ressemblent dans un navigateur. Ensemble, ces quatre sorties séparent une session périmée d’un tunnel cassé.

Notez l’heure de l’interruption, l’heure de la reconnexion et l’écart entre l’ancienne requête et la nouvelle. Cette note transforme une plainte vague en rapport sur lequel quelqu’un peut agir.