Bridge TAP para uma VLAN: conecte a subinterface

Um cliente TAP que alcançava a LAN antes das VLANs e parou depois normalmente ainda tem um bridge contendo a interface errada. O encaminhamento de quadros não adiciona uma tag VLAN, então um quadro de cliente sem tag enviado ao uplink físico chega sem tag numa porta trunk e é descartado ou cai na VLAN nativa. O fato de a subinterface existir em algum lugar no host não muda nada na lista de membros do bridge. Esse é o mito a matar primeiro: a tag é aplicada pela interface que a possui, não pelo host simplesmente ter uma.

Uma extensão de VLAN significa um domínio de camada 2, e o bridge tem que entrar nesse domínio, não no trunk que carrega todos eles.

A tag não aparece porque você fez bridge do trunk

Pegue um uplink Linux eno1 que carrega VLAN 120 para um switch gerenciado. O desenho que funciona para uma VLAN é tap_vpn em bridge com br_vpn, com br_vpn contendo eno1.120 em vez de eno1. A subinterface VLAN aplica a tag na saída e a remove na entrada, então o bridge só vê quadros sem tag para aquela VLAN. Coloque a interface física no bridge em vez disso, e os mesmos quadros saem sem tag numa porta trunk, o que não era o planejado.

Fazer bridge do trunk com a filtragem de VLAN desligada não é atalho para o mesmo resultado. Entrega ao bridge toda VLAN naquele cabo, incluindo as que os clientes não deveriam ver.

Dois desenhos legítimos, um dono da tag

Um bridge ciente de VLAN é o outro arranjo válido: o trunk entra numa porta do bridge, e a associação por porta, o PVID e as configurações de saída com tag decidem quais VLANs passam. Lá o bridge é dono da marcação, e adicionar uma subinterface VLAN abaixo dele instalaria um segundo dono para uma tarefa. Os dois desenhos funcionam; fragmentos dos dois não. Decida qual objeto aplica a tag antes de editar qualquer lista de membros.

A porta do switch tem que concordar com o desenho escolhido. Uma porta access que carrega a VLAN sem tag combina com a interface física como anexo, enquanto uma porta trunk combina com uma subinterface com tag. Adicionar uma subinterface a uma porta access incompatível não conserta nada.

Mova o endereço junto com a associação

No desenho com subinterface, o endereço do host para a sub-rede em bridge pertence a br_vpn, não à porta VLAN escravizada onde ele pode ter morado antes. Deixá-lo na porta pode parecer funcionar e depois se comportar de forma estranha, porque o bridge encaminha na camada 2 enquanto o endereço fica num membro. Mova-o como parte da mudança de associação, não como um experimento separado.

Mover um endereço pode cortar o caminho de administração. Estabeleça uma rota de recuperação independente, salve a configuração existente pelo próprio gerenciador de rede da distribuição e evite um script de inicialização concorrente que brigará com ele após a próxima atualização.

O endereçamento dos clientes exige o mesmo cuidado. Uma VPN em bridge coloca os clientes na sub-rede estendida, então um pool não pode sobrepor outras concessões ou atribuições estáticas, e um arranjo servido por DHCP tem que ser o que a LAN realmente espera. Um caminho de camada 2 funcionando não diz nada sobre endereços duplicados.

Verifique a associação antes de culpar as rotas

Leia o estado atual em vez do pretendido: ip -d link show dev eno1.120 imprime o id da VLAN e seu pai, ip link show master br_vpn lista os membros do bridge, e bridge vlan show relata a associação por porta e o tratamento de saída. No desenho com subinterface, confirme que o dispositivo TAP e o dispositivo VLAN são os membros. Num bridge ciente de VLAN, verifique a própria política da porta, pois um bridge existente não prova o que ele permite.

Depois teste um cliente permitido contra um serviço naquela VLAN, lembrando que ARP, política de firewall e caminho de resposta são questões separadas da associação. Se você capturar pacotes, note que o offload de hardware pode mudar onde as tags VLAN aparecem num trace. Mantenha o escopo honesto também: um cliente TUN roteado não se torna membro de VLAN por nenhuma mudança de bridge, e o tráfego cliente-a-cliente não substitui o anexo do host à VLAN.