VPN connecté mais un service échoue : isoler l’étape

« Connecté » est le fait le moins informatif d’un ticket VPN. Il note que deux pairs ont terminé une poignée de main, et rien sur le nom interrogé, l’interface par laquelle le paquet est sorti, sa taille, ou si l’extrémité distante l’a accepté. C’est pourquoi un service peut échouer alors que toutes les autres applications du même ordinateur portable fonctionnent. Parcourez les étapes dans l’ordre et la première qui échoue nommera la panne.

Commencez par le nom, pas par le tunnel

Résolvez avant de router, car une mauvaise réponse rend chaque test ultérieur inutile. Interrogez le nom avec le résolveur du système et comparez cette réponse à l’adresse que l’application a réellement utilisée. Un nom privé qui revient comme adresse publique signifie que la requête est allée à un résolveur qui n’a rien à y répondre. Un nom qui ne se résout pas est de la même catégorie, juste plus bruyant.

resolvectl query host.internal
getent hosts host.internal

Les navigateurs dotés de leur propre réglage DNS sécurisé échouent ici alors que le reste du système fonctionne. C’est pourquoi une plainte propre au navigateur relève d’abord de cette étape, avant que quiconque touche à une route. Comparez les deux commandes plutôt qu’une seule, car getent suit le chemin NSS et la requête au résolveur non.

Demandez au noyau quel chemin il a choisi

La table de routage est un ordre de préférence, et le chemin choisi par le noyau n’est pas toujours celui du schéma. Demandez-le-lui directement pour la destination concernée. La réponse nomme l’interface, le saut suivant et l’adresse source qui sera utilisée. Un paquet peut sortir par le tunnel en portant une adresse source que l’extrémité distante refuse, et une entrée plus spécifique dans la table physique peut l’envoyer par l’interface Wi-Fi à la place.

ip route get 10.20.30.40
ip -brief address show

Lisez les champs dev, via et src dans cet ordre, car chacun écarte un soupçon différent. Cette étape possède aussi l’état installé par le client, car les règles de pare-feu et les routes peuvent subsister après une sortie anormale. C’est pourquoi « pas d’internet sans le tunnel » et « pas d’internet si le client ne tourne pas » forment une même famille de pannes, et non deux.

Testez la taille du paquet

Une petite réponse qui revient pendant qu’un gros transfert bloque désigne d’abord le MTU du chemin. Une seule sonde avec le bit do-not-fragment activé, envoyée depuis l’intérieur du tunnel, sépare cette étape des autres. Augmentez la charge utile jusqu’à ce que la sonde échoue et vous tenez le nombre qui compte.

ping -M do -s 1400 10.20.30.40

Des sondes courtes qui passent pendant qu’un listage de répertoire ou un envoi se bloque, c’est la signature de cette étape. La plainte évoque des identifiants ou une règle de pare-feu, et elle n’est ni l’un ni l’autre.

Le nombre est une propriété du chemin, pas du client, donc une valeur qui fonctionne sur une connexion de bureau peut échouer sur un lien mobile. Gardez la commande de sonde avec le ticket, car la personne suivante a besoin de la même mesure. Si une charge plus petite passe, le correctif est un clamp ou un MTU de tunnel plus bas, pas un nouveau chiffrement.

Testez l’extrémité distante

Testez la destination par son adresse, puis regardez ce qui écoute là-bas. Une connexion refusée et une connexion qui ne répond jamais sont deux constats différents. La première dit que quelque chose tourne et ne sert pas ce port, et la seconde que rien n’est revenu. Ni l’une ni l’autre n’est un problème de client par défaut.

curl -sv http://10.20.30.41:8080/health
nc -vz -w 3 10.20.30.41 3389
ss -lnt 'sport = :8080'

Rien d’accessible par un tunnel ne peut être un service qui n’écoute que sur 127.0.0.1, car l’écouteur ne voit jamais le paquet. Quand le pare-feu de l’hôte distant autorise le sous-réseau du bureau et refuse le pool du tunnel, le résultat ressemble à une panne de client et n’en est pas une. Le bureau à distance ou le partage de fichiers qui casse alors que le trafic web survit atterrit généralement ici, quelle que soit la formulation de l’utilisateur.

Associez la plainte à une seule étape

La plupart des signalements se ramènent à l’une de cinq formes, et chaque forme nomme une étape. Un site qui ne fonctionne que par le tunnel est une réponse de nom ou une politique liée à l’adresse source. Des mises à jour qui échouent sans le tunnel alors que la navigation fonctionne : c’est un problème de nom ou de route pour ce client.

Que tout s’arrête au démarrage d’un client d’opérateur relève de l’état installé, donc d’une question de route et de pare-feu. Un service injoignable alors que le reste va bien, c’est l’extrémité distante. Des transferts qui bloquent au bout de quelques secondes, c’est la taille du paquet. Faites correspondre la forme avant de lancer des commandes, car elle décide quelles preuves collecter d’abord.

Notez l’étape qui a produit le premier échec avec la sortie de la commande. Un ticket qui dit que l’adresse source était fausse, avec la ligne de route jointe, mérite une action, tandis qu’un ticket qui signale le VPN comme cassé n’en mérite pas.