Pourquoi le proxy Cloudflare ne peut pas transporter OpenVPN sur un seul nom

Une seule machine fait tourner le site web et le serveur OpenVPN, et la tentation est de pointer un seul nom d’hôte vers elle et de laisser le nuage orange démêler le trafic. Le proxy démêle HTTP et HTTPS. Il ne démêle pas une session OpenVPN, quel que soit le port qu’utilise cette session. Deux noms, l’un direct et l’autre proxifié, ne coûtent rien et suppriment toute cette classe de confusion.

Deux noms, deux transports

Donnez au site web un enregistrement proxifié pour que son trafic HTTP et HTTPS passe par Cloudflare. Donnez au VPN un enregistrement DNS seul qui résout directement vers l’entrée publique du VPN, et laissez le client utiliser le port UDP ou TCP pour lequel il est configuré.

Les deux noms peuvent aboutir sur la même machine d’origine. La différence tient à ce qui se passe entre le client et cette machine, et cette différence est tout l’intérêt du partage.

La référence des ports réseau de Cloudflare liste les ports que le proxy web ordinaire accepte. Cette liste concerne HTTP et HTTPS sur ces ports, pas des protocoles arbitraires qui se trouvent partager un numéro.

Le port n’est pas le protocole

Déplacer OpenVPN vers TCP 443 ne le transforme pas en HTTPS. Le proxy attend toujours une requête HTTP au début de la connexion, et un client OpenVPN envoie à la place un message de contrôle binaire. La connexion échoue d’une manière qui ressemble à un blocage réseau parce que rien d’utile n’atteint un journal.

Si l’exigence est vraiment de placer un produit Cloudflare dans le chemin de données du VPN, évaluez-en un qui documente la prise en charge du protocole dont vous avez besoin. Ne supposez pas que le nuage orange est un tunnel TCP ou UDP général, car c’est un proxy inverse pour le trafic web avec une tâche précise.

Un enregistrement DNS seul est la réponse ennuyeuse qui fonctionne, et c’est celle vers laquelle il faut se tourner d’abord.

Une machine a toujours besoin de deux écouteurs

Des noms séparés n’autorisent pas deux processus à lier la même adresse, le même port et le même transport en même temps. Si le serveur web occupe déjà TCP 443 sur toutes les adresses, une instance OpenVPN ne peut pas le prendre aussi sans un arrangement délibéré.

Liez l’écouteur VPN à un autre port, ou à une autre adresse, ou placez devant un multiplexeur documenté et acceptez le coût opérationnel qui va avec. Chacun de ces choix devrait être visible dans les règles du pare-feu, car un écouteur que personne n’a documenté est celui qu’on oublie pendant un incident. Écrivez la liaison retenue dans le même runbook qui décrit le tunnel. Ainsi la personne suivante ne le redécouvrira pas à deux heures du matin.

Les certificats suivent la connexion qu’ils protègent

La connexion TLS du navigateur vers Cloudflare et la connexion de Cloudflare vers votre origine sont deux relations distinctes avec deux certificats distincts. Le navigateur voit un certificat de bord. L’origine présente son propre certificat à Cloudflare, et un certificat Cloudflare Origin CA est prévu exactement pour cette seconde relation.

Ce certificat d’origine est approuvé par Cloudflare en mode Full (strict) et n’est pas un certificat de navigateur approuvé de façon générale. Si quelqu’un visite directement le nom d’hôte DNS seul et reçoit un avertissement, c’est la conséquence attendue d’un chemin de confiance modifié, pas la preuve que le chiffrement s’est arrêté.

Un site web visité directement a donc besoin d’une chaîne de certificats à laquelle ses navigateurs font confiance. Cela peut coexister avec un site proxifié dont l’origine n’est pas destinée à être visitée du tout.

OpenVPN porte sa propre identité de serveur et son authentification de client, avec sa propre autorité de certification et sa propre protection du canal de contrôle. Un cadenas sur le site web ne fournit rien de tout cela, et les deux processus de provisionnement doivent rester séparés.

L’exposition suit le nom

Un enregistrement VPN DNS seul publie l’adresse vers laquelle il pointe. Si cette adresse est aussi l’origine web, l’origine n’est pas cachée, et la décrire comme cachée parce que l’autre nom est proxifié est une erreur qui persiste jusqu’à ce que quelqu’un la scanne.

Décidez quelles requêtes web peuvent atteindre directement l’origine et appliquez-le à l’origine, puis autorisez l’écouteur VPN selon ses propres conditions. Les pages d’administration, les téléchargements de profils et l’écouteur de données peuvent avoir trois exigences d’exposition différentes même quand un seul paquet fournit les trois.

Gardez les liens générés sur le nom web public et le schéma HTTPS, et gardez les profils clients sur le nom du VPN avec le protocole et le port réels. Aucun des deux services ne devrait dépendre du basculement du réglage de proxy de l’autre en fonctionnement normal.

Ordre du travail : nom proxifié pour le site, nom DNS seul pour le VPN, écouteurs distincts, certificat par relation, puis un test qui prouve que chaque nom n’atteint que le service qu’il doit.