Ponte TAP para unha VLAN: conecte a subinterface

Un cliente TAP que chegaba á LAN antes das VLAN e despois deixou de facelo adoita ter unha ponte que aínda contén a interface equivocada. O reenvío de tramas non engade unha etiqueta VLAN, así que unha trama de cliente sen etiqueta enviada ao enlace físico chega sen etiqueta a un porto trunk e ou ben descártase ou ben cae na VLAN nativa. Que a subinterface exista nalgún lugar do host non cambia nada na lista de membros da ponte. Ese é o mito que hai que matar primeiro: a etiqueta aplícaa a interface que a posúe, non o host polo simple feito de ter unha.

Unha extensión dunha soa VLAN significa un só dominio de layer-2, e a ponte ten que unirse a ese dominio en lugar do trunk que as leva todas.

A etiqueta non aparece porque ponteou o trunk

Colla un enlace Linux eno1 que leva a VLAN 120 cara a un conmutador xestionado. O deseño que funciona para unha soa VLAN é tap_vpn ponteado a br_vpn, con br_vpn contendo eno1.120 en lugar de eno1. A subinterface VLAN aplica a etiqueta na saída e quitaa na entrada, así que a ponte só ve tramas sen etiqueta para esa única VLAN. Poña no seu lugar a interface física na ponte e as mesmas tramas saen sen etiqueta por un porto trunk, que non é o que tiña planeado.

Pontear o trunk co filtrado de VLAN desactivado non é un atallo cara ao mesmo resultado. Entrégalle á ponte todas as VLAN dese cable, incluídas as que os clientes non deberían ver.

Dous deseños lexítimos, un só dono da etiqueta

Unha ponte consciente de VLAN é a outra disposición válida: o trunk entra nun porto da ponte, e a pertenza por porto, o PVID e a configuración de saída etiquetada deciden que VLAN pasan. Alí a ponte posúe o etiquetado, e engadir unha subinterface VLAN debaixo instalaría un segundo dono para unha soa tarefa. Ambos os deseños funcionan; as mesturas de ambos non. Decida que obxecto aplica a etiqueta antes de editar calquera lista de membros.

O porto do conmutador ten que coincidir co deseño que elixa. Un porto de acceso que leva a VLAN sen etiqueta emparellase coa interface física como conexión, mentres que un porto trunk se emparella cunha subinterface etiquetada. Engadir unha subinterface a un porto de acceso que non corresponde non arranxa nada.

Mova o enderezo coa pertenza

No deseño con subinterface, o enderezo do host para a subrede ponteada pertence a br_vpn, non ao porto VLAN escravizado onde puido estar antes. Deixalo no porto pode parecer que funciona e despois comportarse de xeito estraño, porque a ponte reenvía en layer 2 mentres o enderezo se asenta nun membro. Móvao como parte do cambio de pertenza e non como un experimento aparte.

Mover un enderezo pode cortar a ruta de administración. Estableza unha ruta de recuperación independente, garde a configuración existente mediante o xestor de rede propio da distribución e evite un script de arranque competidor que loitará con ela tras a próxima actualización.

O direccionamento de clientes necesita o mesmo coidado. Unha VPN ponteada coloca os clientes na subrede estendida, así que un pool non debe solaparse con outras concesións nin asignacións estáticas, e a disposición servida por DHCP ten que ser a que a LAN realmente espera. Unha ruta de layer-2 que funciona non di nada sobre enderezos duplicados.

Verifique a pertenza antes de culpar as rutas

Lea o estado actual e non o previsto: ip -d link show dev eno1.120 imprime o id de VLAN e o seu pai, ip link show master br_vpn lista os membros da ponte e bridge vlan show informa da pertenza por porto e do tratamento de saída. No deseño con subinterface, confirme que o dispositivo TAP e o dispositivo VLAN son os membros. Nunha ponte consciente de VLAN, revise a política do porto en si, porque que exista unha ponte non demostra que permite.

Despois probe un cliente permitido contra un servizo nesa VLAN, recordando que ARP, a política da devasa e a ruta de resposta son asuntos separados da pertenza. Se captura paquetes, teña en conta que a descarga por hardware pode cambiar onde aparecen as etiquetas VLAN nunha traza. Manteña tamén o alcance honesto: un cliente TUN encamiñado non se converte en membro de VLAN por ningún cambio de ponte, e o tráfico cliente-a-cliente non substitúe a conexión do host á VLAN.