Pourquoi un VPN peut sembler connecté alors que rien ne fonctionne

Votre client signale connecté alors que l'interface est montée et que le navigateur expire, et aucune de ces trois affirmations n'est fausse. Connecté décrit une couche qui n'a rien à voir avec la page que vous avez demandée. Déterminer quelle couche signale demande une nouvelle requête et un coup d'œil au compteur qui prouverait que le trafic a circulé. Un redémarrage jette cette preuve et reconstruit les conditions que vous cherchiez à observer.

Trois choses différentes appelées connecté

Tout en bas, connecté peut signifier qu'un processus client tourne et tient une socket vers un pair. Au-dessus, cela peut signifier qu'une interface avec une adresse existe, qu'un appareil persistant ou une routine de récupération peuvent créer sans session vivante derrière. Au niveau du contrôle, cela peut signifier qu'une association a été négociée, ce qui ne dit rien sur le fait qu'un seul paquet l'ait traversée. Chacune survit à des pannes auxquelles les autres ne survivent pas, et un client affiche généralement la plus forte qu'il peut revendiquer.

Une icône verte et un tunnel mort sont donc compatibles plutôt que contradictoires ; ils rendent compte d'objets différents. C'est toute la raison pour laquelle cette panne est sans cesse mal diagnostiquée comme un bug du client.

Envoyez une requête inoffensive vers une destination dont vous avez réellement besoin avant de toucher au démon, et gardez le bloc de trafic direct requis en place pendant que vous travaillez. Un redémarrage efface l'ordre des événements puis les recrée assez près pour masquer la cause, et c'est pourquoi le même ticket revient une semaine plus tard sans rien de nouveau. Une requête, une lecture de compteur et le déclencheur qui a produit la panne constituent la preuve minimale.

Quel compteur prouve que les paquets ont circulé

En IPsec, l'association IKE et l'association CHILD sont des objets distincts, et seul le child porte les compteurs qui répondent à cette question. Listez le child, regardez si les paquets augmentent dans les deux sens, et comparez cela à ce que l'application tente de faire. Une association installée à zéro est une constatation différente d'une association qui augmente alors que l'application échoue encore ; la première signifie que le trafic n'est pas sélectionné, la seconde qu'il circule et que la panne est plus loin. Lisez les compteurs deux fois, à quelques secondes d'intervalle, car un seul échantillon ne peut pas montrer une tendance.

swanctl --list-sas
ip xfrm state list
ip -s link show dev tun0

Des compteurs à zéro pointent vers la sélection : le routage, la politique, un espace de noms d'où le paquet est sorti, ou une interface à laquelle le client ne s'est jamais lié. Des compteurs croissants pointent loin du tunnel, alors continuez avec le transfert à l'extrémité distante, la résolution de noms, le chemin de retour et le service de destination, dans cet ordre. Un protocole sans objet child distinct expose la même preuve dans ses propres termes, alors utilisez ce qu'il rapporte sur l'état du pair et le nombre de paquets au lieu d'emprunter le vocabulaire d'IPsec. La forme de la lecture compte plus que l'outil qui l'a produite.

Où se situe la panne une fois les compteurs en mouvement

Une passerelle qui répond sur sa propre adresse de gestion prouve que la passerelle tourne, pas que quelque chose derrière elle sert votre requête, alors testez le côté distant plutôt que la boîte du milieu. La résolution de noms masque le mieux les pannes, car un résolveur inaccessible par le tunnel expire exactement comme une connexion morte. Deux recherches séparent ces cas, et les deux sont bon marché. Interrogez d'abord le résolveur que le tunnel pousse, puis interrogez un résolveur public pour le même nom.

dig +short host.example
dig +short @10.20.0.1 host.example
ping -c 2 10.20.0.25

Un nom qui se résout via le résolveur public mais pas via celui du tunnel signifie que le chemin DNS est cassé, tandis qu'un nom qui se résout via les deux et expire encore dans le navigateur pointe vers le chemin de retour ou vers le service. Si le ping par adresse réussit et que l'application refuse encore, le réseau a livré la requête et le service l'a rejetée, ce qui est une étape bien plus tardive.

Notez le déclencheur, puis changez une chose

Notez ce qui a précédé la panne : une période d'inactivité, un changement de réseau, un renouvellement de clé, un portable repris ou un système restauré. Ils produisent des mécanismes différents, et seul le système restauré se répare généralement lui-même, ce qui est justement le cas qui ne vous apprend rien. Un redémarrage supprime l'ordre des événements puis recrée des conditions assez proches pour masquer la cause. Écrivez le déclencheur pendant qu'il est encore reproductible.

Faites ensuite une correction étayée et répétez la requête d'origine avec le déclencheur qui a produit la panne. L'inactivité est le déclencheur le plus facile à reproduire, c'est donc la confirmation la plus rapide que la correction a traité le mécanisme et non le symptôme.

Ce que vous voulez rapporter, c'est la preuve que le trafic que vous vouliez envoyer a atteint le service que vous vouliez atteindre. Une icône qui devient verte, une page en cache qui se charge et un compteur qui bouge prouvent tous moins qu'une requête achevée vers la destination prévue. Gardez ensemble la requête, la lecture du compteur et le déclencheur, pour que la personne suivante puisse distinguer une correction d'une coïncidence.