Inspecter une interface VPN Linux avec ip link, couche par couche

L’icône du client indique connecté, l’interface existe, et l’application n’atteint toujours rien. Cette combinaison est courante, car une interface virtuelle peut rester présente alors que son pair distant, ses adresses ou ses routes manquent. ip link est le premier outil à utiliser, et aussi le plus facile à surinterpréter. Les indicateurs et les compteurs décrivent une couche, et les couches au-dessus échouent indépendamment. C’est aussi l’outil que l’on cite pour prouver que le tunnel est monté, précisément l’affirmation qu’il ne peut pas porter seul.

Lisez l’interface avant de lire l’icône

Commencez par ip -details link show dev tun0 comme documenté dans le manuel d’ip-link, en remplaçant par l’interface que votre client possède réellement plutôt que par le nom conventionnel. Les indicateurs, le type, le MTU et l’identité de l’interface sont des observations utiles. La formulation d’état d’une interface virtuelle n’a pas à se comporter comme l’indication de porteuse d’un câble physique ; traitez donc UP comme une affirmation sur l’interface, pas sur le tunnel.

Cette distinction explique le cas le plus déroutant : une interface qui persiste pendant que le côté distant se reconnecte ou est injoignable.

Les réglages de persistance peuvent maintenir le lien précisément pour que la reconnexion ne le reconstruise pas, ce qui signifie que la présence n’est pas la santé.

Ajoutez les compteurs et une requête qui devrait les utiliser

Utilisez la vue de statistiques prise en charge, ip -s link show dev tun0, et notez les compteurs de paquets et d’octets dans les deux sens. Générez ensuite une requête inoffensive qui devrait traverser l’interface et comparez le sens pertinent. Une requête passée par la route directe d’une autre application ne fera pas bouger ces compteurs, et c’est tout l’intérêt de l’exercice.

Si le compteur d’émission bouge et que le compteur de réception ne bouge pas, le paquet est parti et rien n’est revenu. C’est un problème différent d’une interface qui n’a jamais rien transporté. Si les deux compteurs bougent et que l’application échoue toujours, la panne se situe au-dessus de l’interface, ce qui est un progrès et non une impasse.

Relevez la mesure deux fois, une fois avant et une fois après, plutôt que de faire confiance à un seul instantané.

Les adresses et les routes sont des étapes distinctes

Un lien peut exister sans le préfixe, la configuration du résolveur ou la route dont l’application a besoin. Vérifiez l’adresse avec ip address show dev tun0, puis vérifiez quelle route la destination choisirait avec ip route get pour la cible réelle. Ces trois observations répondent à trois questions différentes, et seule la dernière concerne le transfert.

Pour IPsec, la politique de sécurité et l’état de l’association peuvent aussi compter, et toute conception IPsec n’apparaît pas comme une simple interface tun. Chercher un périphérique tun qui n’aurait jamais dû exister est un moyen rapide de conclure à tort.

Notez le nom exact, l’espace de noms et l’heure avec toute sortie que vous conservez, car un nom d’apparence identique dans un autre conteneur ou une session restaurée représente un contexte entièrement différent.

Ne supprimez pas ce que vous n’avez pas identifié

Une interface inconnue n’est pas automatiquement obsolète. Identifiez son propriétaire avant de retirer quoi que ce soit, et utilisez le démontage documenté du client ou la configuration gérée lorsque le retrait est réellement voulu. Supprimer un tunnel actif pour voir ce qui se passe est un test qui répond à une question que personne n’a posée.

Si l’interface appartient à un moteur de conteneurs ou à un espace de noms réseau que vous n’avez pas créé, le propriétaire est à une commande et vaut la peine d’être trouvé d’abord.

Cette prudence vaut aussi pour ip link set down, qui semble réversible et ne l’est souvent pas.

Ce que l’inspection devrait vous laisser

Une bonne inspection se termine par quatre faits : le nom et l’espace de noms de l’interface, ses indicateurs et son MTU, le delta de compteurs issu d’une vraie requête, et la route et l’adresse dont l’application a réellement besoin. Une fois ces faits notés, l’étape suivante est évidente et relève d’une couche précise. Sans eux, chaque modification ultérieure est une supposition assortie d’un plan de retour.

Comparez ces quatre faits aux mêmes quatre d’une session qui fonctionne. Si le nom et l’espace de noms correspondent mais que le delta de compteurs est nul, la requête n’a jamais atteint le tunnel. Si le delta est sain et que la route pointe ailleurs, le tunnel va bien et le routage non. Cette comparaison est ce qui transforme un tas de sorties en décision.

Gardez la sortie avec le ticket, car une comparaison ultérieure n’est utile que si vous voyez ce qui a changé.

Bouclez ensuite en testant à nouveau l’application, car l’interface n’a jamais été ce qui intéressait l’utilisateur.