Un seul serveur TAP ou plusieurs ? Des clients OpenVPN sur un pont

Plusieurs clients TAP n’exigent pas un processus serveur, un port UDP et un périphérique TAP de l’hôte pour chacun. Un serveur OpenVPN en mode Ethernet peut admettre de nombreux clients authentifiés et les rattacher à un seul pont, et c’est la manière documentée d’étendre un segment de couche 2. La conception à un seul processus est celle que documente le manuel, et c’est généralement le bon choix par défaut.

La vraie question est de savoir si ces clients doivent partager ce segment. Le nombre de processus n’y répond pas, car les propriétés d’isolement viennent de la topologie et non du nombre de démons en cours d’exécution. Le reste de cette comparaison porte sur les deux topologies et sur ce que chacune facilite.

Deux architectures, pas deux réglages

Un déploiement TUN routé donne à chaque client une liaison point à point vers le domaine de routage du serveur. Les diffusions s’arrêtent au serveur, les clients ne voient pas les trames des autres, et le trafic entre clients, s’il existe, doit être routé et filtré explicitement.

Un déploiement TAP ponté fait des clients les membres d’un même segment Ethernet. Ils voient les diffusions, peuvent se résoudre mutuellement par ARP et dépendent de la politique du pont et du pare-feu plutôt que du routage pour rester séparés. C’est utile lorsque les clients doivent apparaître comme s’ils étaient branchés sur le même commutateur.

La comparaison porte donc sur ce que les clients doivent atteindre, non sur la performance. Choisissez d’abord la couche, puis décidez combien de processus la servent.

Ce que fait l’assistant server-bridge

L’assistant server-bridge configure le mode Ethernet multi-clients. Sa forme à pool d’adresses prend la passerelle, le masque de réseau et une plage dédiée à l’intérieur du sous-réseau ponté, par exemple une passerelle en 192.168.50.1 avec un pool de 192.168.50.160 à 192.168.50.199.

Réservez cette plage en dehors de toute autre attribution DHCP ou statique. L’assistant y alloue des adresses, mais il ne se coordonne pas avec un autre distributeur sur le même segment, et deux pools qui se chevauchent produisent des adresses en double qui ressemblent à des échecs de connectivité aléatoires. Inscrivez la plage réservée dans le plan d’adressage du site pour que la personne suivante ne la réutilise pas. Un commentaire dans la configuration du serveur est un piètre substitut à cet enregistrement.

Une forme avec mandataire DHCP existe pour les déploiements où un serveur externe distribue les adresses. Elle a ses propres prérequis, et mélanger les deux formes produit exactement le conflit que la documentation signale. Choisissez un seul distributeur pour le sous-réseau ponté.

L’isolement ne vient pas du nombre de processus

Huit processus OpenVPN attachés au même pont sans restriction partagent toujours un domaine de diffusion. Les clients peuvent s’envoyer des ARP à travers le pont, et le nombre d’écouteurs n’y a rien changé.

Si l’exigence est que des groupes de clients ne se voient pas en couche 2, la conception a besoin de ponts séparés ou de raccordements VLAN, avec les règles d’accès qui vont avec. C’est une décision de conception réseau, et c’est la même selon qu’un ou huit processus serveur sont en jeu. Le filtrage du pont peut restreindre une partie du trafic, mais il ne crée pas de domaines de diffusion distincts. Traitez-le comme un complément à la segmentation, non comme un remplacement.

Si l’exigence est seulement que les clients atteignent certains services IP, une conception TUN routée est généralement plus simple que le pontage avec filtrage. Chaque client obtient sa propre liaison, et la politique vit dans les règles de routage et de pare-feu plutôt qu’à l’intérieur du pont.

Quand plusieurs processus restent justifiés

Des processus séparés peuvent se justifier par des besoins d’exploitation : backends d’authentification différents, autorités de certification différentes, cycles de mise à jour distincts ou jeux d’options incompatibles. Ce sont de vraies raisons, et elles sont indépendantes du nombre de clients.

Si vous en utilisez plusieurs, donnez à chacun son propre écouteur et la propriété de son périphérique, et coordonnez les plages d’adresses. Deux serveurs qui croient tous deux posséder le même pool sur le même pont finiront par distribuer la même adresse.

Vérifiez ensuite la conception avec plusieurs clients à la fois. Contrôlez que les adresses sont uniques, que le trafic prévu entre clients fonctionne et qu’une paire qui ne doit pas communiquer ne le peut pas. Un ping réussi depuis un seul client n’éprouve rien de la conception multi-clients.

Lisez le pont et le mode serveur sur l’hôte en fonctionnement avant de faire confiance au schéma. La configuration qui compte est celle que le noyau et le démon ont réellement chargée, et c’est aussi celle qu’un relecteur peut vérifier.