VLAN dei client o un trunk con tag: scegliere la modalità OpenVPN giusta

Arrivano due richieste con una formulazione quasi identica: mettere ogni client VPN in una VLAN scelta, oppure trasportare un trunk VLAN esistente attraverso la VPN. Sono prodotti diversi. La modalità integrata di OpenVPN consapevole delle VLAN è un modello di switch per la prima richiesta, e non è sinonimo di trasporto trasparente dei tag. Scegliere quella sbagliata produce un progetto che sembra configurato e scarta in silenzio le trame che ti interessavano.

Che cosa costruisce davvero la modalità consapevole delle VLAN

Con vlan-tagging attivo in un deployment TAP solo server, il demone modella il proprio dispositivo TAP e ogni client connesso come porte di uno switch interno. Le porte client non sono taggate, e la loro associazione VLAN viene impostata sul server tramite il contesto vlan-pvid per client, non da ciò che il client invia. È tutto il senso del modello: l'appartenenza è una decisione lato server su un peer autenticato. Nulla nel profilo del client deve sapere a quale VLAN appartiene.

Il lato TAP del server riceve una propria politica di accettazione taggata o non taggata tramite vlan-accept. L'inoltro all'interno di quello switch avviene solo tra VID corrispondenti, anche quando client-to-client è impostato, quindi due client in VLAN diverse non possono raggiungersi attraverso il server anche se entrambi vi sono connessi.

Quel modello è un modello a porta di accesso. Le trame che escono da un client non sono taggate, e l'associazione è imposta dal server in base all'identità. Chiedere al portatile di taggare da sé il proprio traffico significa chiedere un altro progetto.

Le assegnazioni devono seguire l'identità autenticata del client, non un valore che il client offre su di sé. Un'assegnazione omessa non è nemmeno uno stato di quarantena: il client finisce sulla PVID predefinita, quindi una voce ccd mancante è una decisione di politica silenziosa e non neutra.

Che cosa richiede invece un trunk trasparente

Trasportare trame già taggate da un capo all'altro inizia disattivando l'elaborazione consapevole delle VLAN. Il modello di switch e la conservazione dei tag sono alternative, e abilitare entrambi chiede a una funzione di fare il lavoro dell'altra.

Disattivarlo è solo l'inizio. Il bridge a ogni estremità e le porte fisiche dello switch devono concordare su quali VLAN sono ammesse, quale tag è nativo e come vengono trattate le trame non taggate. Estendere un trunk senza restrizioni espone molti più domini di broadcast dei due che volevi collegare.

La dimensione delle trame richiede un proprio budget. Una trama Ethernet taggata più l'incapsulamento è più grande della cifra di payload che le persone copiano da una guida, e una MTU adatta a un tunnel instradato non è prova che un percorso trunk funzioni.

Tre condizioni che decidono la risposta

Primo, la piattaforma client supporta TAP? Android e iOS no, e il supporto macOS è limitato, quindi un parco di utenti mobili esclude entrambi i progetti TAP, comunque siano organizzate le VLAN. Una sessione TUN instradata trasporta pacchetti IP, non trame Ethernet, e nessuna configurazione VLAN lato server cambia questo. Controlla il parco prima di progettare la topologia, perché questa è la condizione che non si può aggirare. È anche quella che si scopre più spesso dopo aver finito il lavoro sullo switch.

Secondo, chi assegna la VLAN? Se la risposta è «il server, in base a chi si è autenticato», il modello di switch è adatto. Se la risposta è «l'infrastruttura di switch esistente, con tag già presenti», serve il progetto trunk.

Terzo, quanta parte della rete deve essere raggiungibile? Il modello di switch mantiene ogni client in una sola VLAN per costruzione. Il progetto trunk è un bridge, e un bridge mal configurato unisce domini di broadcast che dovevano restare separati.

Verificare la scelta fatta

Collega un client che dovrebbe stare nella VLAN ammessa e uno che non dovrebbe, poi verifica dall'estremità reale e non dal server stesso. La raggiungibilità lato server dimostra che il bridge o lo switch esiste; non dimostra in quale VLAN sia finito un client.

ip -d link show tap0
bridge vlan show

Sul server, il secondo comando mostra l'appartenenza VLAN di ogni porta del bridge, compreso se una porta è taggata. Confrontala con l'assegnazione prevista prima di fare debug di qualcosa sopra il livello due.

Annota quale dei due progetti usa il deployment. Una nota che dice «consapevole delle VLAN» è ambigua, e l'ingegnere successivo assumerà quello che ha imparato per primo. Il riferimento VLAN di OpenVPNdefinisce il comportamento dello switch e il contesto per client, ed è la via più breve per confermare quale modello stai eseguendo.