Interface TUN orpheline : trouvez le propriétaire avant de la supprimer

Votre interface TUN est toujours répertoriée, le tunnel ne fait pas passer de trafic et le correctif évident ressemble à la suppression du lien. C’est là que de petits nettoyages se transforment en pannes. L’interface peut être persistante par conception, appartenir à un service qui la recréera, ou se cacher dans un espace de noms où le même nom signifie autre chose. Son existence ne prouve pas qu’elle est orpheline.

Supprimer une interface nommée est facile. Savoir ce qui en dépend est la véritable tâche.

Mythe : l’interface est un reste parce que le tunnel est tombé

Un périphérique TUN persistant existe indépendamment d’une session connectée. C’est tout l’intérêt de l’indicateur de persistance : le périphérique reste pour que la prochaine connexion puisse le réutiliser. Aucun trafic ne circule, et rien ne cloche.

L’interface peut aussi appartenir à un service entre deux redémarrages, ou à un client dont le profil est inactif. Vérifiez le processus propriétaire et la configuration avant de conclure qu’elle est abandonnée. Une liste de processus et la configuration qui le lance sont des preuves plus solides qu’un tunnel absent.

Notez l’espace de noms avec le nom. Un autre espace de noms peut contenir une interface du même nom, et les deux n’ont aucun rapport. Utilisez l’indicateur d’espace de noms quand vous devez en inspecter un autre.

Mythe : supprimer le lien nettoie tout

Supprimer le lien retire les adresses et les routes qui y sont attachées. Cela ne supprime pas les règles de stratégie, les règles de pare-feu, les paramètres du résolveur ni les scripts auxiliaires qui y faisaient référence. Ceux-ci peuvent survivre et pointer vers un périphérique qui n’existe plus.

Si le service est encore configuré, il peut recréer l’interface au prochain démarrage ou à la reconnexion. Vous avez alors supprimé une ressource fonctionnelle et laissé le problème de cycle de vie d’origine en place. Modifiez la configuration, pas seulement l’état d’exécution.

Un nettoyage qui se termine par le retour de l’interface et des règles dupliquées est pire que pas de nettoyage du tout.

Trouvez le propriétaire avant d’y toucher

Commencez par ip link show et les outils d’inspection TUN/TAP pour obtenir l’interface, ses adresses et ses routes. Vérifiez le client, le service ou le gestionnaire de réseau qui pourrait la posséder. Confirmez si le périphérique est persistant et quel mode il utilise. Décidez ensuite si quelqu’un en dépend encore.

Pour une interface persistante confirmée inutilisée, ip tuntap documente la suppression propre à chaque mode. Faites correspondre le nom réel du périphérique et le mode, et ne lancez pas un nettoyage large contre chaque tunnel de l’hôte.

Gardez l’accès de récupération et les routes des autres clients intacts pendant votre travail. Notez la commande utilisée pour que la prochaine vérification puisse être répétée exactement.

Retirez-la via le propriétaire, puis vérifiez ce qui reste

Arrêtez ou retirez d’abord la configuration de connexion prise en charge, pour que le service ne recrée pas ce que vous supprimez. Retirez ensuite le périphérique. Ensuite, inspectez les adresses, routes et l’état du résolveur obsolètes sous leurs propres propriétaires.

Si le problème revient à la reconnexion, réparez la configuration du cycle de vie au lieu de répéter la suppression manuelle. Un journal de nettoyage qui nomme l’orpheline, pourquoi elle était inutilisée et quel composant devrait gérer le remplacement évite à la personne suivante de confondre une interface persistante légitime avec une panne.