VLAN de clientes ou un trunk etiquetado: escolla o modo OpenVPN correcto

Chegan dúas solicitudes cunha redacción case idéntica: pór cada cliente VPN nunha VLAN escollida, ou transportar un trunk VLAN existente a través da VPN. Son produtos distintos. O modo integrado de OpenVPN consciente de VLAN é un modelo de conmutador para a primeira solicitude, e non é sinónimo de transporte transparente de etiquetas. Escoller o incorrecto produce un deseño que parece configurado e descarta en silencio as tramas que lle importaban.

Que constrúe realmente o modo consciente de VLAN

Con vlan-tagging activado nunha implantación TAP só de servidor, o daemon modela o seu dispositivo TAP e cada cliente conectado como portos dun conmutador interno. Os portos de cliente non van etiquetados, e a súa asociación de VLAN fíxase no servidor mediante o contexto vlan-pvid por cliente, non por nada que envíe o cliente. Ese é o sentido do modelo: a pertenza é unha decisión do lado do servidor sobre un par autenticado. Nada no perfil do cliente necesita saber a que VLAN pertence.

O lado TAP do servidor recibe a súa propia política de aceptación etiquetada ou non etiquetada mediante vlan-accept. O reenvío dentro dese conmutador só ocorre entre VID coincidentes, mesmo cando client-to-client está definido, así que dous clientes en VLAN distintas non poden alcanzarse a través do servidor aínda que ambos estean conectados a el.

Ese modelo é un modelo de porto de acceso. As tramas que saen dun cliente non van etiquetadas, e a asociación impona o servidor segundo a identidade. Pedirlle ao portátil que etiquete o seu propio tráfico é pedir outro deseño.

As asignacións deben seguir a identidade autenticada do cliente, non un valor que o cliente ofreza sobre si mesmo. Unha asignación omitida tampouco é un estado de corentena: o cliente cae no PVID predeterminado, así que unha entrada ccd ausente é unha decisión de política silenciosa e non neutra.

Que esixe en cambio un trunk transparente

Transportar tramas xa etiquetadas de extremo a extremo comeza por desactivar o procesamento consciente de VLAN. O modelo de conmutador e a conservación de etiquetas son alternativas, e activar ambos pide a unha función que faga o traballo da outra.

Desactivalo é só o principio. A ponte de cada extremo e os portos físicos do conmutador deben coincidir en que VLAN se permiten, que etiqueta é nativa e como se tratan as tramas non etiquetadas. Estender un trunk sen restricións expón moitos máis dominios de difusión que os dous que quería conectar.

O tamaño da trama necesita o seu propio orzamento. Unha trama Ethernet etiquetada máis a encapsulación é maior que a cifra de carga útil que a xente copia dunha guía, e unha MTU que ía ben para un túnel encamiñado non é proba de que un camiño de trunk funcione.

Tres condicións que deciden a resposta

Primeiro, a plataforma do cliente admite TAP? Android e iOS non, e o soporte de macOS é limitado, así que un parque de usuarios móbiles descarta calquera dos dous deseños TAP, independentemente de como se organicen as VLAN. Unha sesión TUN encamiñada transporta paquetes IP, non tramas Ethernet, e ningunha configuración de VLAN no servidor o cambia. Revise o parque antes de deseñar a topoloxía, porque esta condición é a que non se pode evitar. Tamén é a condición que máis a miúdo se descobre despois de rematar o traballo no conmutador.

Segundo, quen asigna a VLAN? Se a resposta é «o servidor, segundo quen se autenticou», encaixa o modelo de conmutador. Se a resposta é «a infraestrutura de conmutadores existente, con etiquetas que xa existen», necesita o deseño de trunk.

Terceiro, que parte da rede debería ser alcanzable? O modelo de conmutador mantén cada cliente nunha VLAN por construción. O deseño de trunk é unha ponte, e unha ponte mal configurada une dominios de difusión que debían permanecer separados.

Probar a escolla que fixo

Conecte un cliente que debería estar na VLAN permitida e outro que non, e despois probe desde o extremo real en lugar de desde o propio servidor. A alcanzabilidade desde o servidor demostra que a ponte ou o conmutador existe; non demostra en que VLAN caeu un cliente.

ip -d link show tap0
bridge vlan show

No servidor, o segundo comando mostra a pertenza a VLAN de cada porto da ponte, incluído se un porto está etiquetado ou non. Compáreo coa asignación que pretendía antes de depurar nada por riba da capa dous.

Anote cal dos dous deseños usa a implantación. Unha nota que diga «consciente de VLAN» é ambigua, e o seguinte enxeñeiro asumirá o que aprendeu primeiro. A referencia de VLAN de OpenVPNdefine o comportamento do conmutador e o contexto por cliente, e é o camiño máis curto para confirmar que modelo está a executar.