VLAN de clients o un trunk etiquetat: trieu el mode OpenVPN correcte

Arriben dues peticions amb una redacció gairebé idèntica: poseu cada client VPN en una VLAN triada, o transporteu un trunk VLAN existent a través de la VPN. Són productes diferents. El mode integrat d'OpenVPN conscient de VLAN és un model de commutador per a la primera petició, i no és sinònim de transport transparent d'etiquetes. Triar el dolent produeix un disseny que sembla configurat i descarta silenciosament les trames que us importaven.

Què construeix realment el mode conscient de VLAN

Amb vlan-tagging activat en un desplegament TAP només de servidor, el dimoni modela el seu dispositiu TAP i cada client connectat com a ports d'un commutador intern. Els ports de client no van etiquetats, i la seva associació de VLAN es fixa al servidor mitjançant el context vlan-pvid per client, no per res que enviï el client. Aquest és el punt central del model: la pertinença és una decisió del costat del servidor sobre un parell autenticat. Res del perfil del client no ha de saber a quina VLAN pertany.

El costat TAP del servidor obté la seva pròpia política d'acceptació etiquetada o no etiquetada mitjançant vlan-accept. L'encaminament dins d'aquest commutador només passa entre VID coincidents, també quan client-to-client està definit, de manera que dos clients en VLAN diferents no es poden arribar a través del servidor encara que tots dos hi estiguin connectats.

Aquest model és un model de port d'accés. Les trames que surten d'un client no van etiquetades, i l'associació la imposa el servidor segons la identitat. Demanar a l'ordinador portàtil que etiqueti el seu propi trànsit és demanar un altre disseny.

Les assignacions han de seguir la identitat autenticada del client, no un valor que el client ofereixi sobre si mateix. Una assignació omesa tampoc no és un estat de quarantena: el client cau al PVID per defecte, així que una entrada ccd absent és una decisió de política silenciosa i no pas neutra.

Què exigeix en canvi un trunk transparent

Transportar trames ja etiquetades d'un extrem a l'altre comença per desactivar el processament conscient de VLAN. El model de commutador i la preservació d'etiquetes són alternatives, i activar tots dos demana a una funció que faci la feina de l'altra.

Desactivar-ho és només el començament. El pont de cada extrem i els ports físics del commutador han de coincidir en quines VLAN es permeten, quina etiqueta és nativa i com es tracten les trames no etiquetades. Estendre un trunk sense restriccions exposa molts més dominis de difusió que els dos que volíeu connectar.

La mida de la trama necessita el seu propi pressupost. Una trama Ethernet etiquetada més l'encapsulament és més gran que la xifra de càrrega útil que la gent copia d'una guia, i una MTU que anava bé per a un túnel encaminat no és prova que un camí de trunk funcioni.

Tres condicions que decideixen la resposta

Primer, la plataforma del client admet TAP? Android i iOS no, i el suport de macOS és limitat, així que una flota d'usuaris mòbils descarta qualsevol disseny TAP, sigui com sigui que s'organitzin les VLAN. Una sessió TUN encaminada transporta paquets IP, no trames Ethernet, i cap configuració de VLAN al servidor ho canvia. Reviseu la flota abans de dissenyar la topologia, perquè aquesta condició és la que no es pot evitar. També és la condició que es descobreix més sovint un cop acabada la feina del commutador.

Segon, qui assigna la VLAN? Si la resposta és «el servidor, segons qui s'ha autenticat», el model de commutador encaixa. Si la resposta és «la infraestructura de commutadors existent, amb etiquetes que ja existeixen», us cal el disseny de trunk.

Tercer, quina part de la xarxa ha de ser abastable? El model de commutador manté cada client en una VLAN per construcció. El disseny de trunk és un pont, i un pont mal configurat uneix dominis de difusió que havien de quedar separats.

Comprovar l'elecció que heu fet

Connecteu un client que hauria de ser a la VLAN permesa i un que no, i després proveu des de l'extrem real i no des del servidor mateix. L'abastabilitat des del servidor demostra que el pont o el commutador existeix; no demostra en quina VLAN ha caigut un client.

ip -d link show tap0
bridge vlan show

Al servidor, la segona ordre mostra la pertinença a VLAN de cada port del pont, inclòs si un port està etiquetat o no. Compareu-ho amb l'assignació que preteníeu abans de depurar res per sobre de la capa dos.

Anoteu quin dels dos dissenys fa servir el desplegament. Una nota que digui «conscient de VLAN» és ambigua, i el següent enginyer assumirà el que va aprendre primer. La referència de VLAN d'OpenVPNdefineix el comportament del commutador i el context per client, i és el camí més curt per confirmar quin model esteu executant.