Servir OpenVPN sur TCP et UDP depuis un seul hôte
Avant la 2.7, un processus lie un seul transport. Comparez une paire TAP pontée, deux sous-réseaux TUN et un pool partagé, puis associez chaque profil à son écouteur.
Les réseaux qui n'autorisent que TCP 443 cohabitent avec des réseaux qui laissent passer UDP sans problème, et un serveur doit servir les deux. Un profil avec proto udp répond au second groupe et échoue sur le premier, et modifier la même configuration pour dire proto tcp ne crée pas un second écouteur. La directive choisit un transport pour un processus. Tout le reste découle de cette contrainte.
Soit vous exécutez plus d'un processus, soit vous exécutez une version capable de lier plusieurs sockets à la fois.
Avant la 2.7, un processus lie un seul transport
La version communautaire d' OpenVPN lie le socket que décrit proto , et cette directive choisit un seul transport pour l'instance. TCP et UDP sont des piles distinctes, donc le même numéro de port peut être occupé par les deux en même temps, mais pas par un seul processus. La branche 2.6 vous donne donc un transport par démon. OpenVPN 2.7 a supprimé cette limitation pour les serveurs, qui peuvent lier plusieurs sockets via plusieurs --local dans un même processus.
Vérifiez la version avant de concevoir autour de l'une ou l'autre réponse, car la disposition 2.7 est un autre modèle d'exploitation avec sa propre syntaxe de configuration. Un guide écrit pour la 2.6 décrit deux processus même lorsqu'il ne le dit pas.
Trois façons d'exécuter deux instances
Avec des interfaces TAP, exécutez une instance par transport et pontez les deux périphériques tap sur l'hôte. Les deux ensembles de clients aboutissent dans le même domaine de diffusion, ce qui permet à un seul pool d'adresses de les couvrir et maintient le fonctionnement des protocoles dépendant de la diffusion. Avec TUN, le pontage n'est pas disponible, donc la division la plus simple donne à chaque instance son propre sous-réseau et laisse le routage séparer les deux ensembles de clients. Une troisième option conserve un seul pool en faisant appeler à chaque instance un script learn-address qui installe une route /32 pour le client via le périphérique de cette instance.
C'est cette troisième disposition que les gens demandent et celle qui exige le plus de soin, car le script devient une partie du chemin de données et doit traiter correctement les événements d'ajout, de mise à jour et de suppression.
| Arrangement | Interfaces | Address pool | Cost |
|---|---|---|---|
| Bridged TAP pair | Two tap devices joined by a bridge | One shared pool | Broadcast traffic and bridge maintenance |
| Two TUN subnets | Two tun devices, no bridge | One pool per instance | Routing rules and two plans |
| Shared pool with routes | Two tun devices plus a hook | One pool across both | A script on the data path |
Gardez les deux instances séparées
Chaque instance a aussi besoin d'un port ou d'une adresse distincts, d'un fichier d'état distinct et d'une destination de journal distincte. Deux démons qui écrivent dans un même fichier d'état produisent une sortie illisible pendant un incident, alors que c'est précisément le moment où vous en avez besoin. Si une seconde instance lie une adresse précise, cette adresse doit exister sur l'hôte au démarrage du processus ; sinon il se termine par un échec de liaison avant de dire quoi que ce soit sur les clés.
Nommez les unités et les profils de sorte que le transport soit évident d'après le nom du fichier . L'opérateur suivant ne devrait pas avoir à ouvrir une configuration pour savoir laquelle est en TCP.
Associez le profil à l'écouteur
Un serveur qui exécute proto tcp attend un profil client avec proto tcp-client , et un profil qui porte encore proto udp face à cet écouteur expire sans erreur sur laquelle l'utilisateur puisse agir . Gardez deux profils si le déploiement propose les deux transports, et étiquetez-les pour que le support voie lequel a été essayé. Le numéro de port seul ne décrit pas le transport.
Les règles de pare-feu suivent la même séparation : une règle pour UDP 1194 ne dit rien de TCP 1194, et une règle pour une adresse ne couvre pas l'autre écouteur.
Lisez d'abord la vue du serveur
Commencez par ss -lntup sur le serveur et confirmez qu'un écouteur TCP et un écouteur UDP apparaissent. Connectez ensuite un client de chaque type et vérifiez que la sortie d'état contient deux entrées avec des adresses distinctes. Si les sockets existent et qu'aucun client n'arrive, le chemin ou le pare-feu refuse les paquets avant que le démon ne les voie.
Un socket qui n'apparaît jamais est un problème de configuration ou de liaison, et un socket qui apparaît mais ne journalise jamais de connexion est un problème de filtrage. Du point de vue du client, les deux se ressemblent, c'est pourquoi la vue du serveur lui-même vient en premier. Gardez en tête que TCP apporte le blocage en tête de file, donc l'offrir est une mesure d'accessibilité et non une amélioration pour les clients disposant d'un chemin UDP propre.