¿Un servidor TAP o varios? Clientes OpenVPN en un puente

Varios clientes TAP no exigen un proceso de servidor, un puerto UDP y un dispositivo TAP del host para cada uno. Un servidor OpenVPN en modo Ethernet puede admitir muchos clientes autenticados y conectarlos a un único puente, y esa es la forma documentada de extender un segmento de capa 2. El diseño de un solo proceso es el que documenta el manual y suele ser el valor predeterminado correcto.

La verdadera pregunta es si esos clientes deberían compartir ese segmento. El número de procesos no la responde, porque las propiedades de aislamiento vienen de la topología y no de cuántos demonios se ejecutan. El resto de esta comparación trata de las dos topologías y de lo que cada una facilita.

Dos arquitecturas, no dos ajustes

Un despliegue TUN enrutado da a cada cliente un enlace punto a punto hacia el dominio de enrutamiento del servidor. Las difusiones se detienen en el servidor, los clientes no ven las tramas de los demás y el tráfico entre clientes, si existe, debe enrutarse y filtrarse de forma explícita.

Un despliegue TAP puenteado convierte a los clientes en miembros de un mismo segmento Ethernet. Ven las difusiones, pueden resolverse entre sí con ARP y dependen de la política del puente y del cortafuegos en lugar del enrutamiento para mantenerse separados. Eso es útil cuando los clientes deben aparecer como si estuvieran conectados al mismo conmutador.

La comparación trata, por tanto, de a qué deben llegar los clientes, no del rendimiento. Elija primero la capa y luego decida cuántos procesos la sirven.

Qué hace el asistente server-bridge

El asistente server-bridge configura el modo Ethernet para varios clientes. Su forma de grupo de direcciones toma la puerta de enlace, la máscara de red y un rango dedicado dentro de la subred puenteada, por ejemplo una puerta de enlace en 192.168.50.1 con un grupo de 192.168.50.160 a 192.168.50.199.

Reserve ese rango fuera de cualquier otra asignación DHCP o estática. El asistente asigna direcciones de él, pero no se coordina con otro asignador en el mismo segmento, y dos grupos solapados producen direcciones duplicadas que parecen fallos de conectividad aleatorios. Escriba el rango reservado en el plan de direcciones del sitio para que la siguiente persona no lo reutilice. Un comentario en la configuración del servidor es un sustituto pobre de ese registro.

Existe una forma con proxy DHCP para despliegues en los que un servidor externo reparte direcciones. Tiene sus propios requisitos previos, y mezclar las dos formas produce exactamente el conflicto que advierte la documentación. Elija un solo asignador para la subred puenteada.

El aislamiento no viene del número de procesos

Ocho procesos OpenVPN conectados al mismo puente sin restricciones siguen compartiendo un dominio de difusión. Los clientes pueden hacer ARP entre ellos a través del puente, y el número de escuchas no cambió nada de eso.

Si el requisito es que grupos de clientes no se vean entre sí en la capa 2, el diseño necesita puentes separados o conexiones VLAN, junto con las reglas de acceso correspondientes. Es una decisión de diseño de red y es la misma tanto si interviene un proceso de servidor como ocho. El filtrado del puente puede restringir parte del tráfico, pero no crea dominios de difusión separados. Trátelo como un complemento de la segmentación, no como un sustituto.

Si el requisito es solo que los clientes lleguen a determinados servicios IP, un diseño TUN enrutado suele ser más sencillo que puentear con filtrado. Cada cliente obtiene su propio enlace y la política vive en las reglas de enrutamiento y del cortafuegos en lugar de en el interior del puente.

Cuándo varios procesos siguen siendo correctos

Los procesos separados pueden justificarse por necesidades operativas: distintos backends de autenticación, distintas autoridades de certificación, ciclos de actualización separados o conjuntos de opciones incompatibles. Son razones reales y son independientes del número de clientes.

Si usa varios, dé a cada uno su propio escucha y la propiedad de su dispositivo, y coordine los rangos de direcciones. Dos servidores que ambos creen poseer el mismo grupo en el mismo puente acabarán repartiendo la misma dirección.

Después verifique el diseño con varios clientes a la vez. Compruebe que las direcciones sean únicas, que el tráfico previsto entre clientes funcione y que una pareja que no debe comunicarse no pueda hacerlo. Un ping correcto de un solo cliente no ejercita nada del diseño para varios clientes.

Lea el puente y el modo del servidor desde el host en ejecución antes de confiar en el diagrama. La configuración que importa es la que el núcleo y el demonio cargaron realmente, y es también la que un revisor puede comprobar.