Ponte TAP per una sola VLAN: collegate la sottointerfaccia

Un client TAP che raggiungeva la LAN prima delle VLAN e poi si è fermato di solito ha un ponte che contiene ancora l'interfaccia sbagliata. L'inoltro dei frame non aggiunge un tag VLAN, quindi un frame client senza tag inviato all'uplink fisico arriva senza tag su una porta trunk e viene scartato oppure finisce nella VLAN nativa. Il fatto che la sottointerfaccia esista da qualche parte sull'host non cambia nulla nell'elenco dei membri del ponte. È questo il mito da uccidere per primo: il tag lo applica l'interfaccia che lo possiede, non l'host solo perché ne ha una.

Un'estensione di una sola VLAN significa un solo dominio layer-2, e il ponte deve unirsi a quel dominio invece che al trunk che le porta tutte.

Il tag non compare perché avete ponticellato il trunk

Prendete un uplink Linux eno1 che porta la VLAN 120 verso uno switch gestito. Il progetto che funziona per una sola VLAN è tap_vpn ponticellato su br_vpn, con br_vpn che contiene eno1.120 invece di eno1. La sottointerfaccia VLAN applica il tag in uscita e lo rimuove in entrata, quindi il ponte vede solo frame senza tag per quella singola VLAN. Mettete invece l'interfaccia fisica nel ponte e gli stessi frame escono senza tag su una porta trunk, che non è ciò che avevate pianificato.

Ponticellare il trunk con il filtraggio VLAN disattivato non è una scorciatoia verso lo stesso risultato. Consegna al ponte ogni VLAN su quel cavo, comprese quelle che i client non dovrebbero vedere.

Due progetti legittimi, un solo proprietario del tag

Un ponte consapevole delle VLAN è l'altra disposizione valida: il trunk entra in una porta del ponte, e l'appartenenza per porta, il PVID e le impostazioni di uscita con tag decidono quali VLAN passano. Lì il ponte possiede il tagging, e aggiungere una sottointerfaccia VLAN sotto di esso installerebbe un secondo proprietario per un solo compito. Entrambi i progetti funzionano; i frammenti di entrambi no. Decidete quale oggetto applica il tag prima di modificare qualsiasi elenco di membri.

La porta dello switch deve concordare con il progetto che scegliete. Una porta access che porta la VLAN senza tag si abbina all'interfaccia fisica come collegamento, mentre una porta trunk si abbina a una sottointerfaccia con tag. Aggiungere una sottointerfaccia a una porta access inadatta non ripara nulla.

Spostate l'indirizzo con l'appartenenza

Nel progetto con sottointerfaccia, l'indirizzo dell'host per la sottorete ponticellata appartiene a br_vpn, non alla porta VLAN schiavizzata dove poteva trovarsi prima. Lasciarlo sulla porta può sembrare funzionare e poi comportarsi in modo strano, perché il ponte inoltra a layer 2 mentre l'indirizzo siede su un membro. Spostatelo come parte del cambio di appartenenza e non come esperimento separato.

Spostare un indirizzo può tagliare il percorso di amministrazione. Stabilite una rotta di ripristino indipendente, salvate la configurazione esistente tramite il gestore di rete della distribuzione stessa ed evitate uno script di avvio concorrente che combatterà con essa dopo il prossimo aggiornamento.

L'indirizzamento dei client richiede la stessa cura. Una VPN ponticellata colloca i client nella sottorete estesa, quindi un pool non deve sovrapporsi ad altri lease o assegnazioni statiche, e la disposizione servita da DHCP deve essere quella che la LAN si aspetta davvero. Un percorso layer-2 funzionante non dice nulla sugli indirizzi duplicati.

Verificate l'appartenenza prima di dare la colpa alle rotte

Leggete lo stato attuale invece di quello previsto: ip -d link show dev eno1.120 stampa l'id VLAN e il suo genitore, ip link show master br_vpn elenca i membri del ponte e bridge vlan show riporta l'appartenenza per porta e il trattamento in uscita. Nel progetto con sottointerfaccia, confermate che il dispositivo TAP e il dispositivo VLAN siano i membri. In un ponte consapevole delle VLAN, controllate la politica della porta stessa, perché un ponte esistente non dimostra cosa consente.

Poi provate un client consentito contro un servizio in quella VLAN, ricordando che ARP, la politica del firewall e il percorso di ritorno sono questioni separate dall'appartenenza. Se catturate pacchetti, notate che l'offload hardware può cambiare dove compaiono i tag VLAN in una traccia. Mantenete onesto anche l'ambito: un client TUN instradato non diventa membro di una VLAN per nessun cambio di ponte, e il traffico client-a-client non sostituisce il collegamento dell'host alla VLAN.