Router les clients OpenVPN via Cloudflare ? Vérifiez d’abord le rôle

Vous avez un serveur OpenVPN opérationnel et un hôte qui exécute aussi le logiciel d’appareil de Cloudflare, et la prochaine étape évidente consiste apparemment à diriger le trafic des clients vers lui. Deux connexions opérationnelles sur une même machine ne forment pas une passerelle de transit. Ce qui manque, c’est un rôle documenté pour transmettre des paquets qui appartiennent à quelqu’un d’autre, et une politique qui classe ces paquets à leur arrivée.

Avant toute règle viennent quatre questions : quel trafic entre, où il va ensuite, comment les réponses retrouvent leur chemin, et ce que fait la conception lorsque ce second chemin échoue. Les deux premières sont des questions de capacité.

Deux services sur un même hôte ne font pas un chemin de transit

Un client d’appareil est conçu pour gérer le trafic qui prend naissance sur la machine où il s’exécute. Il intercepte la résolution de noms, ou un trafic applicatif sélectionné, et l’envoie dans son propre tunnel, et sa politique est écrite pour l’utilisateur de cet appareil et les processus de cet appareil. Un paquet transmis depuis un client OpenVPN n’est pas une sortie locale, donc les mêmes règles ne le classent pas. Ce n’est pas un détail de configuration que l’on peut masquer avec une règle plus large, car il détermine si le logiciel voit le paquet tout court.

C’est pourquoi la question de conception est une question de capacité. Soit le produit installé possède un rôle documenté qui transmet le trafic d’autres réseaux, soit la fonction de transit appartient à un tout autre endroit.

Quel rôle de Cloudflare a le droit de transmettre

Le client d’appareil de Cloudflare propose des modes qui diffèrent par leur portée : résolution de noms seule, trafic de l’appareil, et parfois les deux. Aucun de ces modes ne transforme l’hôte en routeur pour une plage privée qui arrive par un autre tunnel. Le rôle de routage dédié est un produit distinct avec son propre connecteur, son enregistrement et son modèle de réseau.

Vérifiez le rôle installé avant de concevoir des routes autour de lui. Lisez quelle interface le connecteur crée, s’il annonce des préfixes précis ou une route par défaut, et si la politique locale s’applique aux paquets transmis comme aux paquets locaux. Si seul le trafic local est traité, le serveur OpenVPN ne peut pas être le point de transit, quelle que soit la rédaction de la règle de traduction.

C’est aussi ici qu’une exigence de sortie publique doit être formulée précisément. Une sortie fournie par Cloudflare pour le trafic client transmis est un cas d’usage précis, et il faut la confirmer face au service que vous avez réellement.

Gardez le tunnel extérieur indépendant de la nouvelle route

À l’instant où vous ajoutez une route par défaut vers la nouvelle interface, le trafic sortant propre du serveur commence à la disputer, et cela inclut les réponses aux clients OpenVPN et votre session SSH vers la machine. Le symptôme habituel est un tunnel qui s’établit puis meurt, ou un administrateur enfermé dehors alors que le changement semble avoir fonctionné. Comparez ip route get pour le point de terminaison avant et après, et utilisez le routage par politique ou une route d’hôte pour garder le transport propre du serveur là où il était. Exécutez cette comparaison depuis la machine elle-même, car c’est la vision du serveur sur sa propre route qui compte.

Une exception pour l’adresse publique du serveur ne suffit pas en soi, car le chemin de retour de chaque administrateur distant est un flux différent. Décidez lesquels de ces flux doivent survivre au changement, puis vérifiez chacun au lieu de supposer que le premier couvre les autres.

Limitez la transmission et la traduction à un seul flux

Les paquets reçus suivent le chemin de transmission, pas celui de la sortie locale, donc la règle qui compte vit dans le hook forward. Là où l’interface suivante a besoin d’une traduction, limitez la source au pool de clients, la destination à ce qui est autorisé et la sortie à cette seule interface. Une règle masquerade liée uniquement à une interface ne choisit aucune route d’elle-même et n’autorise pas la transmission au-delà d’un autre filtre.

Décidez du comportement de fermeture en cas d’échec à l’avance, puis testez-le. Arrêtez le chemin suivant et confirmez que les clients perdent la sortie prévue au lieu de retomber silencieusement sur la liaison montante ordinaire, car c’est le résultat que personne ne remarque avant que le trafic ne sorte par la mauvaise porte. Répétez la vérification pour la résolution de noms et pour IPv6, car un jeu de règles limité à v4 laisse un chemin v6 ouvert.

Notez les quatre réponses sur lesquelles vous vous êtes arrêté et l’observation qui démontre chacune. Un chemin de transit que vous pouvez décrire est un chemin que vous pouvez défendre lors de la prochaine revue d’incidents.