VLAN-uri de client sau un trunk etichetat: alegeți modul OpenVPN corect

Sosesc două cereri cu o formulare aproape identică: puneți fiecare client VPN într-un VLAN ales, sau transportați un trunk VLAN existent prin VPN. Sunt produse diferite. Modul integrat al OpenVPN conștient de VLAN este un model de switch pentru prima cerere și nu este sinonim cu transportul transparent de etichete. Alegerea greșită produce un proiect care pare configurat și aruncă în tăcere cadrele care vă interesau.

Ce construiește de fapt modul conștient de VLAN

Cu vlan-tagging activat într-o implementare TAP doar pentru server, demonul modelează dispozitivul său TAP și fiecare client conectat ca porturi ale unui switch intern. Porturile de client nu sunt etichetate, iar asocierea lor VLAN se stabilește pe server prin contextul vlan-pvid pentru fiecare client, nu prin ceea ce trimite clientul. Acesta este tot rostul modelului: apartenența este o decizie de pe partea serverului despre un partener autentificat. Nimic din profilul clientului nu trebuie să știe cărui VLAN aparține.

Partea TAP a serverului primește propria politică de acceptare etichetată sau neetichetată prin vlan-accept. Comutarea în interiorul acelui switch are loc doar între VID identice, inclusiv când client-to-client este setat, așa că doi clienți din VLAN-uri diferite nu se pot atinge prin server, deși amândoi sunt conectați la el.

Acest model este un model de port de acces. Cadrele care pleacă de la un client nu sunt etichetate, iar asocierea este impusă de server pe baza identității. A cere laptopului să își eticheteze singur traficul înseamnă a cere alt proiect.

Atribuirile trebuie să urmeze identitatea autentificată a clientului, nu o valoare pe care clientul o oferă despre sine. O atribuire omisă nu este nici stare de carantină: clientul ajunge pe PVID-ul implicit, deci o intrare ccd lipsă este o decizie de politică silențioasă, nu una neutră.

Ce cere în schimb un trunk transparent

Transportarea cadrelor deja etichetate de la un capăt la altul începe prin dezactivarea procesării conștiente de VLAN. Modelul de switch și păstrarea etichetelor sunt alternative, iar activarea ambelor cere unei funcții să facă munca celeilalte.

Dezactivarea este doar începutul. Puntea de la fiecare capăt și porturile fizice ale switchului trebuie să cadă de acord asupra VLAN-urilor permise, asupra etichetei native și asupra modului de tratare a cadrelor neetichetate. Extinderea unui trunk fără restricții expune mult mai multe domenii de difuzare decât cele două pe care voiați să le conectați.

Dimensiunea cadrului are nevoie de propriul buget. Un cadru Ethernet etichetat plus încapsulare este mai mare decât cifra de payload pe care oamenii o copiază dintr-un ghid, iar o MTU potrivită pentru un tunel rutat nu dovedește că o cale de trunk funcționează.

Trei condiții care decid răspunsul

În primul rând, platforma clientului suportă TAP? Android și iOS nu, iar suportul macOS este limitat, așa că un parc de utilizatori mobili exclude ambele proiecte TAP, indiferent cum sunt aranjate VLAN-urile. O sesiune TUN rutată transportă pachete IP, nu cadre Ethernet, iar nicio configurație VLAN de pe server nu schimbă asta. Verificați parcul înainte de a proiecta topologia, pentru că aceasta este condiția care nu poate fi ocolită. Este și condiția descoperită cel mai des după terminarea lucrărilor la switch.

În al doilea rând, cine atribuie VLAN-ul? Dacă răspunsul este «serverul, pe baza cine s-a autentificat», modelul de switch se potrivește. Dacă răspunsul este «infrastructura existentă de switchuri, cu etichete care există deja», aveți nevoie de proiectul de trunk.

În al treilea rând, cât de mult din rețea ar trebui să fie accesibil? Modelul de switch ține fiecare client într-un singur VLAN prin construcție. Proiectul de trunk este o punte, iar o punte configurată greșit unește domenii de difuzare care trebuiau să rămână separate.

Testarea alegerii făcute

Conectați un client care ar trebui să fie în VLAN-ul permis și unul care nu ar trebui, apoi testați de la capătul real, nu de la serverul însuși. Accesibilitatea din partea serverului dovedește că puntea sau switchul există; nu dovedește în ce VLAN a ajuns clientul.

ip -d link show tap0
bridge vlan show

Pe server, a doua comandă arată apartenența VLAN a fiecărui port de punte, inclusiv dacă portul este etichetat. Comparați-o cu atribuirea intenționată înainte de a depana orice deasupra nivelului doi.

Notați care dintre cele două proiecte este folosit de implementare. O notă care spune «conștient de VLAN» este ambiguă, iar următorul inginer va presupune varianta pe care a învățat-o primul. Referința VLAN a OpenVPNdefinește comportamentul switchului și contextul pentru fiecare client, și este cea mai scurtă cale de a confirma ce model rulați.