Puente TAP para una VLAN: conecte la subinterfaz

Un cliente TAP que llegaba a la LAN antes de las VLAN y después dejó de hacerlo suele tener un puente que todavía contiene la interfaz equivocada. El reenvío de tramas no añade una etiqueta VLAN, así que una trama de cliente sin etiqueta enviada al enlace físico llega sin etiqueta a un puerto trunk y o bien se descarta o bien cae en la VLAN nativa. Que la subinterfaz exista en algún lugar del host no cambia nada en la lista de miembros del puente. Ese es el mito que hay que matar primero: la etiqueta la aplica la interfaz que la posee, no el host por el simple hecho de tener una.

Una extensión de una sola VLAN significa un solo dominio de layer-2, y el puente tiene que unirse a ese dominio en lugar del trunk que las lleva todas.

La etiqueta no aparece porque puenteó el trunk

Tome un enlace Linux eno1 que lleva la VLAN 120 hacia un conmutador gestionado. El diseño que funciona para una sola VLAN es tap_vpn puenteado a br_vpn, con br_vpn conteniendo eno1.120 en lugar de eno1. La subinterfaz VLAN aplica la etiqueta a la salida y la quita a la entrada, así que el puente solo ve tramas sin etiqueta para esa única VLAN. Ponga en su lugar la interfaz física en el puente y las mismas tramas salen sin etiqueta por un puerto trunk, que no es lo que había planeado.

Puentear el trunk con el filtrado de VLAN desactivado no es un atajo hacia el mismo resultado. Le entrega al puente todas las VLAN de ese cable, incluidas las que los clientes no deberían ver.

Dos diseños legítimos, un solo dueño de la etiqueta

Un puente consciente de VLAN es la otra disposición válida: el trunk entra en un puerto del puente, y la pertenencia por puerto, el PVID y la configuración de salida etiquetada deciden qué VLAN pasan. Allí el puente posee el etiquetado, y añadir una subinterfaz VLAN debajo instalaría un segundo dueño para una sola tarea. Ambos diseños funcionan; las mezclas de ambos no. Decida qué objeto aplica la etiqueta antes de editar cualquier lista de miembros.

El puerto del conmutador tiene que coincidir con el diseño que elija. Un puerto de acceso que lleva la VLAN sin etiqueta se empareja con la interfaz física como conexión, mientras que un puerto trunk se empareja con una subinterfaz etiquetada. Añadir una subinterfaz a un puerto de acceso que no corresponde no arregla nada.

Mueva la dirección junto con la pertenencia

En el diseño con subinterfaz, la dirección del host para la subred puenteada pertenece a br_vpn, no al puerto VLAN esclavizado donde pudo haber estado antes. Dejarla en el puerto puede parecer que funciona y luego comportarse de forma extraña, porque el puente reenvía en layer 2 mientras la dirección se asienta en un miembro. Muévala como parte del cambio de pertenencia y no como un experimento aparte.

Mover una dirección puede cortar la ruta de administración. Establezca una ruta de recuperación independiente, guarde la configuración existente mediante el gestor de red propio de la distribución y evite un script de arranque competidor que peleará con ella tras la próxima actualización.

El direccionamiento de clientes necesita el mismo cuidado. Una VPN puenteada coloca a los clientes en la subred extendida, así que un pool no debe solaparse con otras concesiones ni asignaciones estáticas, y la disposición servida por DHCP tiene que ser la que la LAN realmente espera. Una ruta de layer-2 que funciona no dice nada sobre direcciones duplicadas.

Verifique la pertenencia antes de culpar a las rutas

Lea el estado actual y no el previsto: ip -d link show dev eno1.120 imprime el id de VLAN y su padre, ip link show master br_vpn lista los miembros del puente y bridge vlan show informa de la pertenencia por puerto y del tratamiento de salida. En el diseño con subinterfaz, confirme que el dispositivo TAP y el dispositivo VLAN son los miembros. En un puente consciente de VLAN, revise la política del puerto en sí, porque que exista un puente no demuestra qué permite.

Después pruebe un cliente permitido contra un servicio en esa VLAN, recordando que ARP, la política del cortafuegos y la ruta de respuesta son asuntos separados de la pertenencia. Si captura paquetes, tenga en cuenta que la descarga por hardware puede cambiar dónde aparecen las etiquetas VLAN en una traza. Mantenga también el alcance honesto: un cliente TUN enrutado no se convierte en miembro de VLAN por ningún cambio de puente, y el tráfico cliente-a-cliente no sustituye la conexión del host a la VLAN.