Klientaj VLAN-oj aŭ etikeda trunk: elektu la ĝustan OpenVPN-reĝimon

Du petoj alvenas kun preskaŭ sama vortigo: metu ĉiun VPN-klienton en elektitan VLAN-on, aŭ portu ekzistantan VLAN-trunk tra la VPN. Ili estas malsamaj produktoj. La enkonstruita VLAN-konscia reĝimo de OpenVPN estas komutila modelo por la unua peto, kaj ĝi ne estas sinonimo de travidebla etikeda transporto. Elekti la malĝustan produktas dezajnon, kiu aspektas agordita kaj silente forĵetas la kadrojn, kiuj gravis al vi.

Kion la VLAN-konscia reĝimo fakte konstruas

Kun vlan-tagging ŝaltita en TAP-disdonigo nur por servilo, la demono modeligas sian TAP-aparaton kaj ĉiun konektitan klienton kiel havenojn de interna komutilo. Klientaj havenoj estas senetikaj, kaj ilia VLAN-asocio estas fiksita sur la servilo per la vlan-pvid-kunteksto por ĉiu kliento, ne per io, kion la kliento sendas. Tio estas la tuta senco de la modelo: membreco estas decido de la servila flanko pri aŭtentikigita samtavolano. Nenio en la klienta profilo bezonas scii, al kiu VLAN ĝi apartenas.

La TAP-flanko de la servilo ricevas sian propran akceptpolitikon por etikedaj aŭ senetikaj kadroj per vlan-accept. Plusendado ene de tiu komutilo okazas nur inter kongruaj VID-oj, ankaŭ kiam client-to-client estas agordita, do du klientoj en malsamaj VLAN-oj ne povas atingi unu la alian tra la servilo, kvankam ambaŭ estas konektitaj al ĝi.

Tiu modelo estas alirporta modelo. Kadroj forlasantaj klienton estas senetikaj, kaj la asocion trudas la servilo surbaze de identeco. Peti la tekkomputilon mem etikedi sian trafikon estas peti alian dezajnon.

Asignoj devas sekvi la aŭtentikigitan klientan identecon, ne valoron, kiun la kliento proponas pri si mem. Mankanta asigno ankaŭ ne estas kvarantena stato: la kliento alteriĝas sur la defaŭltan PVID, do mankanta ccd-ero estas silenta politika decido, ne neŭtrala.

Kion anstataŭe postulas travidebla trunk

Porti jam etikeditajn kadrojn de fino al fino komenciĝas per malŝalto de la VLAN-konscia prilaborado. La komutila modelo kaj konservado de etikedoj estas alternativoj, kaj ŝalti ambaŭ petas de unu trajto fari la laboron de la alia.

Malŝalti ĝin estas nur la komenco. La ponto ĉe ĉiu finpunkto kaj la fizikaj komutilaj havenoj devas interkonsenti, kiuj VLAN-oj estas permesitaj, kiu etikedo estas indiĝena kaj kiel senetikaj kadroj estas traktataj. Etendi senrestriktan trunk elmontras multe pli da dissendaj domajnoj ol la du, kiujn vi intencis konekti.

Kadra grandeco bezonas sian propran buĝeton. Etikeda Ethernet-kadro plus enkapsuligo estas pli granda ol la utilŝarĝa nombro, kiun homoj kopias el gvidilo, kaj MTU, kiu taŭgis por enkursigita tunelo, ne pruvas, ke trunk-vojo funkcias.

Tri kondiĉoj, kiuj decidas la respondon

Unue, ĉu la klienta platformo entute subtenas TAP-on? Android kaj iOS ne subtenas, kaj la subteno de macOS estas limigita, do aro da movaj uzantoj ekskludas ĉiun TAP-dezajnon sendepende de tio, kiel la VLAN-oj estas aranĝitaj. Enkursigita TUN-sesio portas IP-paketojn, ne Ethernet-kadrojn, kaj nenia kvanto da servila VLAN-agordo tion ŝanĝas. Kontrolu la aron antaŭ ol desegni la topologion, ĉar ĉi tiu kondiĉo estas la sola, kiun oni ne povas eviti. Ĝi ankaŭ estas la kondiĉo plej ofte malkovrata post ol la komutila laboro finiĝis.

Due, kiu asignas la VLAN-on? Se la respondo estas «la servilo, surbaze de tio, kiu aŭtentikigis», la komutila modelo taŭgas. Se la respondo estas «la ekzistanta komutila infrastrukturo, kun etikedoj, kiuj jam ekzistas», vi bezonas la trunk-dezajnon.

Trie, kiom da la reto devus esti atingebla? La komutila modelo konstrue tenas ĉiun klienton en unu VLAN. La trunk-dezajno estas ponto, kaj mise agordita ponto kunigas dissendajn domajnojn, kiuj devis resti apartaj.

Testi la elekton, kiun vi faris

Konektu unu klienton, kiu devus esti en la permesita VLAN, kaj unu, kiu ne devus, tiam testu de la reala finpunkto anstataŭ de la servilo mem. Atingebleco de la servila flanko pruvas, ke la ponto aŭ komutilo ekzistas; ĝi ne pruvas, en kiu VLAN kliento alteriĝis.

ip -d link show tap0
bridge vlan show

Sur la servilo, la dua komando montras la VLAN-membrecon de ĉiu ponta haveno, inkluzive ĉu haveno estas etikeda aŭ ne. Komparu tion kun la asigno, kiun vi intencis, antaŭ ol sencimigi ion ajn super la dua tavolo.

Notu, kiun el la du dezajnoj la disdonigo uzas. Noto «VLAN-konscia» estas ambigua, kaj la sekva inĝeniero supozos tiun, kiun li lernis unue. La OpenVPN-VLAN-referencodifinas la komutilan konduton kaj la kuntekston por ĉiu kliento, kaj ĝi estas la plej mallonga vojo por konfirmi, kiun modelon vi funkciigas.