VLANs de clientes ou um trunk marcado: escolha o modo OpenVPN correto

Chegam dois pedidos com uma redação quase idêntica: colocar cada cliente VPN numa VLAN escolhida, ou transportar um trunk VLAN existente através da VPN. São produtos diferentes. O modo integrado do OpenVPN consciente de VLAN é um modelo de switch para o primeiro pedido, e não é sinónimo de transporte transparente de etiquetas. A escolha errada produz um desenho que parece configurado e descarta silenciosamente as tramas que lhe importavam.

O que o modo consciente de VLAN constrói na prática

Com vlan-tagging ativo numa implementação TAP apenas de servidor, o daemon modela o seu dispositivo TAP e cada cliente ligado como portas de um switch interno. As portas de cliente não são marcadas, e a sua associação de VLAN é definida no servidor através do contexto vlan-pvid por cliente, e não por algo que o cliente envie. É todo o sentido do modelo: a pertença é uma decisão do lado do servidor sobre um par autenticado. Nada no perfil do cliente precisa de saber a que VLAN pertence.

O lado TAP do servidor recebe a sua própria política de aceitação marcada ou não marcada através de vlan-accept. O encaminhamento dentro desse switch só acontece entre VID iguais, incluindo quando client-to-client está definido, pelo que dois clientes em VLAN diferentes não se alcançam através do servidor, embora ambos estejam ligados a ele.

Esse modelo é um modelo de porta de acesso. As tramas que saem de um cliente não são marcadas, e a associação é imposta pelo servidor com base na identidade. Pedir ao portátil que marque o seu próprio tráfego é pedir outro desenho.

As atribuições devem seguir a identidade autenticada do cliente, não um valor que o cliente ofereça sobre si mesmo. Uma atribuição omitida também não é um estado de quarentena: o cliente cai no PVID predefinido, pelo que uma entrada ccd em falta é uma decisão de política silenciosa e não neutra.

O que um trunk transparente exige em vez disso

Transportar tramas já marcadas de ponta a ponta começa por desativar o processamento consciente de VLAN. O modelo de switch e a preservação de etiquetas são alternativas, e ativar ambos pede a uma funcionalidade que faça o trabalho da outra.

Desativar é apenas o início. A ponte em cada extremidade e as portas físicas do switch têm de concordar sobre que VLAN são permitidas, que etiqueta é nativa e como são tratadas as tramas não marcadas. Estender um trunk sem restrições expõe muito mais domínios de difusão do que os dois que queria ligar.

O tamanho da trama precisa do seu próprio orçamento. Uma trama Ethernet marcada mais o encapsulamento é maior do que o número de carga útil que as pessoas copiam de um guia, e uma MTU que servia para um túnel encaminhado não prova que um caminho de trunk funcione.

Três condições que decidem a resposta

Primeiro, a plataforma do cliente suporta TAP? O Android e o iOS não, e o suporte de macOS é limitado, pelo que um parque de utilizadores móveis exclui qualquer dos dois desenhos TAP, independentemente de como as VLAN estão organizadas. Uma sessão TUN encaminhada transporta pacotes IP, não tramas Ethernet, e nenhuma configuração de VLAN no servidor muda isso. Verifique o parque antes de desenhar a topologia, porque é esta a condição que não se pode contornar. É também a condição que mais frequentemente se descobre depois de terminado o trabalho no switch.

Segundo, quem atribui a VLAN? Se a resposta for «o servidor, com base em quem se autenticou», encaixa o modelo de switch. Se a resposta for «a infraestrutura de switches existente, com etiquetas que já existem», precisa do desenho de trunk.

Terceiro, que parte da rede deve ser alcançável? O modelo de switch mantém cada cliente numa VLAN por construção. O desenho de trunk é uma ponte, e uma ponte mal configurada junta domínios de difusão que deviam ficar separados.

Testar a escolha feita

Ligue um cliente que devia estar na VLAN permitida e outro que não devia, e depois teste a partir da extremidade real e não do próprio servidor. A alcançabilidade do lado do servidor prova que a ponte ou o switch existe; não prova em que VLAN o cliente ficou.

ip -d link show tap0
bridge vlan show

No servidor, o segundo comando mostra a pertença à VLAN de cada porta da ponte, incluindo se a porta está marcada. Compare isso com a atribuição que pretendia antes de depurar seja o que for acima da camada dois.

Registe qual dos dois desenhos a implementação usa. Uma nota que diga «consciente de VLAN» é ambígua, e o engenheiro seguinte vai assumir aquele que aprendeu primeiro. A referência de VLAN do OpenVPNdefine o comportamento do switch e o contexto por cliente, e é o caminho mais curto para confirmar que modelo está a executar.