Où se situe TLS dans OpenVPN et ce qui change la forme

OpenVPN utilise bien TLS, et les gens étendent régulièrement cela à une affirmation qu’il ne peut pas porter : qu’un tunnel ressemble donc à un navigateur visitant un site. La première partie est vraie. La seconde ne l’est pas. Ici, TLS appartient à un canal de contrôle qui circule à l’intérieur du propre conteneur d’OpenVPN, à côté d’un canal de charge utile à la cryptographie entièrement différente, de sorte que qui inspecte les premiers octets voit OpenVPN.

Deux conversations dans une enveloppe

Pensez une session comme deux conversations partageant une même enveloppe. L’une valide des certificats et dérive le matériel de clé. L’autre chiffre ce que vous envoyez réellement, à partir de ce que la première a produit.

L’enveloppe est le protocole. Chaque paquet commence par un petit en-tête qui nomme son type, et cet en-tête arrive avant tout le reste.

Ce qui arrive réellement en premier

À cause de cet ordre, la première chose sur le fil n’est pas un enregistrement TLS. C’est l’en-tête d’OpenVPN, suivi du contenu du canal que l’en-tête annonce. Un ClientHello existe là-dedans, simplement pas à l’octet zéro. Aucun déchiffrement n’est nécessaire pour remarquer la différence, car la forme seule la trahit.

Les valeurs par défaut comptent aussi ici. Le flux est en UDP vers 1194, sauf si le profil choisit TCP. Dans les deux cas, l’apparence extérieure est un tunnel et non une requête web.

Trois façons honnêtes de changer la forme

Un terminateur TLS comme stunnel accepte TLS sur un port à chaque extrémité et remet le flux déchiffré à OpenVPN localement, de sorte que le réseau voit du TLS vers ce port. Un protocole qui est TLS dès le premier octet se comporte encore autrement : l’échange compatible AnyConnect qu’implémente ocserv ressemble à l’accès distant d’entreprise que beaucoup de réseaux attendent déjà. SSTP, fourni avec Windows, possède la même propriété dans un autre produit.

Sous Linux, l’option -w de SSH transporte une liaison point à point à l’intérieur d’une session SSH, ce qui est utile quand SSH est le seul protocole autorisé. C’est la moins coûteuse des quatre si SSH fonctionne déjà depuis ce réseau, et la moins utile sinon.

Ce qu’aucune d’elles ne change

Aucune de ces options ne change ce que le tunnel peut atteindre. Elles ne rendent pas une adresse bloquée joignable, elles n’authentifient personne et elles ne décident pas des routes.

Un enrobage vous coûte aussi un composant. Deux écouteurs et deux fichiers de configuration signifient deux endroits de panne, et les deux se ressemblent depuis la place de l’utilisateur. Budgétez cela avant d’en adopter un. La session reste un seul flux chiffré de longue durée vers une destination, et son volume comme son minutage restent visibles.

Diagnostiquez d’abord, choisissez ensuite

Diagnostiquez donc d’abord. L’UDP abandonné se traite par le mode TCP, et une signature reconnue se traite par un autre protocole ou un enrobage. Choisir un outil avant de connaître le blocage, c’est ainsi que les gens finissent par maintenir trois couches qui échouent toutes pour la même raison.

Un réseau qui n’autorise que les ports web réduit le choix à un protocole fondé sur TLS sur le 443. Appliquer les trois à la fois donne une pile que personne ne peut déboguer, alors changez une chose et retestez le même flux.

Si aucune ne s’applique, la réponse exacte est que ce réseau ne portera pas de tunnel pour vous. C’est un constat et non un échec de l’effort. Parcourir davantage d’options n’annule pas une décision de politique prise en amont.

Une limite se dresse devant tout cela. L’autorisation d’exploiter un tunnel sur le réseau de quelqu’un d’autre est une question de politique, décidée séparément du fait que le mécanisme fonctionne. Ces faits expliquent ce qu’un observateur voit, et ils n’accordent pas d’autorisation.