OpenVPN TUN ou TAP : trois conditions qui tranchent

Deux tunnels peuvent transporter le même transfert de fichiers et différer complètement par ce qu’ils posent sur le fil. L’un déplace des paquets IP entre deux adresses ; l’autre déplace des trames Ethernet et peut être ponté dans un segment. Cette différence décide quelles applications fonctionnent, quels clients peuvent se connecter et combien de conception réseau vous acceptez.

Trois conditions tranchent en pratique. Parcourez-les dans l’ordre, car la première met généralement fin à la discussion.

Ce que chaque interface transporte réellement

Un périphérique TUN est une interface point à point de couche 3 : le noyau lui remet des paquets IP et le tunnel les porte vers une adresse homologue. Un périphérique TAP est une interface de couche 2 qui transporte des trames Ethernet, et c’est précisément ce qui rend le pontage possible, comme le décrit la documentation du noyau. Ni l’un ni l’autre ne change la façon dont la charge utile est chiffrée, et aucun n’est un réglage de force. Le choix porte sur ce que les extrémités doivent échanger, pas sur la qualité de la protection du trafic.

Une conséquence suit immédiatement : les deux extrémités doivent être d’accord. Un client configuré pour un type de périphérique ne peut pas rejoindre un serveur configuré pour l’autre, quoi que le reste fasse correspondre.

Condition une : quelque chose a-t-il besoin de la couche deux ?

Le pontage justifie sa complexité lorsqu’un protocole a réellement besoin du même domaine de diffusion : trafic non IP, découverte qui ne peut pas traverser un routeur, ou application qui exige d’être sur un même segment. Tout le reste est un problème de routage, et le routage le règle avec bien moins de machinerie. Étendre un segment sur une zone étendue étend aussi ses diffusions, si bien que la prévention des boucles, le plan d’adressage et les domaines de panne font partie de la conception. C’est beaucoup accepter pour une exigence qu’une seule route aurait satisfaite.

Le test est concret : nommez l’application qui échoue sur un tunnel routé et dites pourquoi. Si la réponse est qu’il lui faut de la diffusion, la couche deux est la réponse honnête. Si la réponse est que quelqu’un ne pouvait pas joindre un serveur, l’exigence est une route ou une règle de pare-feu.

Condition deux : les clients en sont-ils capables ?

La prise en charge n’est pas uniforme. Les clients de bureau exposent généralement les deux types de périphérique, tandis que les clients mobiles et embarqués n’implémentent souvent que le mode routé, et un profil qui s’importe sans protestation peut encore échouer lorsqu’il tente de créer l’interface. Vérifiez le client et la version précis plutôt que de déduire les capacités du nom de la plateforme.

Une erreur d’option non prise en charge n’est pas une invitation à supprimer des lignes inconnues jusqu’à ce que l’importation réussisse. Elle signifie que le profil et le client ne sont pas d’accord sur ce qui est possible, et la réparation revient à l’opérateur qui a émis le profil. Retirer une option pour faire taire un validateur peut produire une connexion qui semble fonctionner tout en omettant silencieusement la propriété pour laquelle elle existait.

Condition trois : est-ce vraiment une question d’interface ?

Deux choix voisins sont blâmés pour les problèmes d’interface. Le périphérique virtuel décide de ce qui entre dans le tunnel, tandis que UDP ou TCP décide du comportement du transport extérieur, et aucun des deux ne guérit les transferts qui se bloquent. Quand les gros transferts se bloquent alors que les petits réussissent, la taille des paquets et le MTU méritent l’attention.

Un client qui se connecte puis n’atteint pas un hôte interne regarde généralement le routage, une règle de pare-feu ou un chemin de retour manquant.

Pour un service géré, utilisez l’agencement d’interfaces que spécifie le profil de l’opérateur, car le côté serveur est déjà bâti autour. Pour un déploiement privé, choisissez à partir de l’exigence réelle de l’application et écrivez la raison à côté du choix.

La question n’est pas de savoir quelle option est la plus forte. C’est de savoir de laquelle le trafic a réellement besoin.