VLAN de clientes o un trunk etiquetado: elija el modo OpenVPN correcto

Llegan dos solicitudes con una redacción casi idéntica: poner cada cliente VPN en una VLAN elegida, o transportar un trunk VLAN existente a través de la VPN. Son productos distintos. El modo integrado de OpenVPN consciente de VLAN es un modelo de conmutador para la primera solicitud, y no es sinónimo de transporte transparente de etiquetas. Elegir el equivocado produce un diseño que parece configurado y descarta en silencio las tramas que le importaban.

Qué construye realmente el modo consciente de VLAN

Con vlan-tagging activado en un despliegue TAP solo de servidor, el demonio modela su dispositivo TAP y cada cliente conectado como puertos de un conmutador interno. Los puertos de cliente no van etiquetados, y su asociación de VLAN se fija en el servidor mediante el contexto vlan-pvid por cliente, no por nada que envíe el cliente. Ese es el sentido del modelo: la pertenencia es una decisión del lado del servidor sobre un par autenticado. Nada en el perfil del cliente necesita saber a qué VLAN pertenece.

El lado TAP del servidor recibe su propia política de aceptación etiquetada o no etiquetada mediante vlan-accept. El reenvío dentro de ese conmutador solo ocurre entre VID coincidentes, incluso cuando client-to-client está definido, así que dos clientes en VLAN distintas no pueden alcanzarse a través del servidor aunque ambos estén conectados a él.

Ese modelo es un modelo de puerto de acceso. Las tramas que salen de un cliente no van etiquetadas, y la asociación la impone el servidor según la identidad. Pedir al portátil que etiquete su propio tráfico es pedir otro diseño.

Las asignaciones deben seguir la identidad autenticada del cliente, no un valor que el cliente ofrezca sobre sí mismo. Una asignación omitida tampoco es un estado de cuarentena: el cliente cae en el PVID predeterminado, así que una entrada ccd ausente es una decisión de política silenciosa y no neutra.

Qué exige en cambio un trunk transparente

Transportar tramas ya etiquetadas de extremo a extremo empieza por desactivar el procesamiento consciente de VLAN. El modelo de conmutador y la conservación de etiquetas son alternativas, y activar ambos pide a una función que haga el trabajo de la otra.

Desactivarlo es solo el principio. El puente de cada extremo y los puertos físicos del conmutador deben coincidir en qué VLAN se permiten, qué etiqueta es nativa y cómo se tratan las tramas no etiquetadas. Extender un trunk sin restricciones expone muchos más dominios de difusión que los dos que quería conectar.

El tamaño de trama necesita su propio presupuesto. Una trama Ethernet etiquetada más la encapsulación es mayor que la cifra de carga útil que la gente copia de una guía, y una MTU que iba bien para un túnel enrutado no es prueba de que un camino de trunk funcione.

Tres condiciones que deciden la respuesta

Primero, ¿la plataforma del cliente admite TAP? Android e iOS no, y el soporte de macOS es limitado, así que un parque de usuarios móviles descarta cualquiera de los dos diseños TAP sin importar cómo se organicen las VLAN. Una sesión TUN enrutada transporta paquetes IP, no tramas Ethernet, y ninguna configuración de VLAN en el servidor lo cambia. Revise el parque antes de diseñar la topología, porque esta condición es la que no se puede evitar. También es la condición que más a menudo se descubre después de terminar el trabajo en el conmutador.

Segundo, ¿quién asigna la VLAN? Si la respuesta es «el servidor, según quién se autenticó», encaja el modelo de conmutador. Si la respuesta es «la infraestructura de conmutadores existente, con etiquetas que ya existen», necesita el diseño de trunk.

Tercero, qué parte de la red debería ser alcanzable? El modelo de conmutador mantiene a cada cliente en una VLAN por construcción. El diseño de trunk es un puente, y un puente mal configurado une dominios de difusión que debían permanecer separados.

Probar la elección que hizo

Conecte un cliente que debería estar en la VLAN permitida y otro que no, y luego pruebe desde el extremo real en lugar de desde el propio servidor. La alcanzabilidad desde el servidor demuestra que el puente o el conmutador existe; no demuestra en qué VLAN cayó un cliente.

ip -d link show tap0
bridge vlan show

En el servidor, el segundo comando muestra la pertenencia a VLAN de cada puerto del puente, incluido si un puerto está etiquetado o no. Compárelo con la asignación que pretendía antes de depurar nada por encima de la capa dos.

Anote cuál de los dos diseños usa el despliegue. Una nota que diga «consciente de VLAN» es ambigua, y el siguiente ingeniero asumirá el que aprendió primero. La referencia de VLAN de OpenVPNdefine el comportamiento del conmutador y el contexto por cliente, y es el camino más corto para confirmar qué modelo está ejecutando.