Ce que fait TUN et ce que le protocole VPN doit encore faire

Traiter tun0 et un protocole VPN comme une seule chose envoie les gens vers le mauvais journal. L’interface est une frontière locale où un programme en espace utilisateur échange des paquets IP avec le noyau. Le protocole est ce que ce programme fait des paquets une fois qu’il les a : transport, authentification, chiffrement et un pair. Créer le périphérique ne choisit rien de tout cela.

Deux composants, un seul chemin de paquets

Le noyau écrit un paquet IP dans le périphérique, et le programme le lit depuis un descripteur de fichier. Dans l’autre sens, le programme réécrit un paquet et le noyau le route comme s’il était arrivé sur une interface réelle. TUN transporte de l’IP, tandis que TAP transporte des trames Ethernet. Lire un paquet à cette frontière montre l’encapsulation, et c’est exactement à cela que sert le périphérique.

Tout ce qui se trouve au-delà de cette frontière est l’affaire du programme. Deux programmes peuvent utiliser le même concept d’interface et faire des choses totalement différentes avec les paquets. Le périphérique lui-même n’a aucun avis sur ce qui se passe ensuite. Le descripteur de fichier est la seule prise que le programme possède du côté noyau.

Créez le périphérique, puis observez la frontière

Créez un périphérique délibérément lorsque vous testez la frontière. Un périphérique persistant survit au processus qui l’a créé, ce qui est utile pour les expériences et une source courante de confusion ensuite. Vérifiez les indicateurs et le propriétaire avant d’accuser le VPN.

sudo ip tuntap add dev tun9 mode tun user alice
ip -d link show tun9

Le détail du lien montre le type de périphérique et le propriétaire associé. Si aucun processus ne le garde ouvert, les paquets qui y sont écrits ne vont nulle part. Un périphérique sans processus associé peut sembler sain dans une liste de liens tout en ne faisant rien passer.

Ce que le nom de l’interface ne peut pas promettre

Le nom de l’interface ne dit rien du chiffrement ni de l’authentification. Un programme peut envelopper les paquets dans TLS, dans un protocole maison, dans IPsec ou dans rien du tout. Choisir TUN plutôt que TAP change l’encapsulation à la frontière, pas la conception de sécurité. Le choix d’encapsulation est réel, et il est bien plus petit que la question de sécurité.

La détection fonctionne de la même manière : un observateur voit le protocole externe sur le fil, pas une étiquette indiquant quel périphérique local l’a produit. Un tunnel qui ressemble à autre chose le fait à cause de son protocole externe, pas à cause du nom de son interface. Un observateur ne peut pas voir quel périphérique local a produit un paquet, seulement à quoi ressemble le paquet. Gardez ces deux questions séparées lorsque vous comparez des produits, car une réponse n’implique jamais l’autre.

Adaptez la correction à l’étape qui échoue

Séparez les étapes de défaillance lorsque quelque chose casse. Un périphérique absent, une erreur de permissions et une connexion refusée produisent des preuves et des corrections différentes. Lisez d’abord l’état local, puis le journal du programme, puis le point de vue du pair. Lisez les trois avant de changer quoi que ce soit.

ip -d link show tun0
journalctl -u openvpn-client@corp --since '10 min ago'

Si le périphérique existe et qu’un processus le tient, la frontière locale fonctionne et le problème est plus loin. Si le périphérique manque, aucune vérification des identifiants n’aidera. Une étape que vous pouvez nommer est une étape que vous pouvez tester. La documentation TUN/TAP décrit la frontière et le modèle du périphérique.