Klientu VLAN vai ar atzīmēts trunk: izvēlieties pareizo OpenVPN režīmu

Pienāk divi gandrīz vienādi formulēti pieprasījumi: ievietot katru VPN klientu izvēlētā VLAN vai pārnest esošu VLAN trunk caur VPN. Tie ir divi dažādi produkti. OpenVPN iebūvētais VLAN apzinīgais režīms ir komutatora modelis pirmajam pieprasījumam, un tas nav caurspīdīgas atzīmju pārsūtīšanas sinonīms. Nepareiza izvēle rada risinājumu, kas izskatās konfigurēts, bet klusi izmet tos kadrus, kas jums bija svarīgi.

Ko VLAN apzinīgais režīms patiešām veido

Kad vlan-tagging ir ieslēgts tikai servera TAP izvietojumā, dēmons modelē savu TAP ierīci un katru pievienoto klientu kā iekšēja komutatora portus. Klientu porti ir bez atzīmes, un to VLAN saistījums tiek noteikts serverī, izmantojot katra klienta vlan-pvid kontekstu, nevis to, ko klients sūta. Tā ir visa modeļa būtība: dalība ir servera puses lēmums par autentificētu partneri. Nekam klienta profilā nav jāzina, kurai VLAN tas pieder.

Servera TAP puse iegūst savu atzīmēto vai neatzīmēto kadru pieņemšanas politiku, izmantojot vlan-accept. Pārsūtīšana šajā komutatorā notiek tikai starp atbilstošiem VID, tostarp tad, kad ir iestatīts client-to-client, tāpēc divi klienti dažādos VLAN nevar sasniegt viens otru caur serveri, lai gan abi ir tam pievienoti.

Šis modelis ir piekļuves porta modelis. Kadri, kas iziet no klienta, ir bez atzīmes, un saistījumu uzspiež serveris, pamatojoties uz identitāti. Lūgt klēpjdatoram pašam atzīmēt savu trafiku nozīmē lūgt citu risinājumu.

Piešķīrumiem jāseko autentificētajai klienta identitātei, nevis vērtībai, ko klients piedāvā par sevi. Izlaists piešķīrums arī nav karantīnas stāvoklis: klients nonāk uz noklusējuma PVID, tāpēc trūkstošs ccd ieraksts ir kluss politikas lēmums, nevis neitrāls.

Ko tā vietā prasa caurspīdīgs trunk

Jau atzīmētu kadru pārnese no gala līdz galam sākas ar VLAN apzinīgās apstrādes izslēgšanu. Komutatora modelis un atzīmju saglabāšana ir alternatīvas, un abu ieslēgšana lūdz vienai funkcijai darīt otras darbu.

Izslēgšana ir tikai sākums. Tiltam katrā galā un fiziskajiem komutatora portiem jāvienojas, kuras VLAN ir atļautas, kura atzīme ir vietējā un kā apstrādā neatzīmētus kadrus. Neierobežota trunk paplašināšana atklāj daudz vairāk apraides domēnu nekā tie divi, kurus gribējāt savienot.

Kadra izmēram nepieciešams savs budžets. Atzīmēts Ethernet kadrs plus iekapsulēšana ir lielāks par lietderīgās kravas skaitli, ko cilvēki nokopē no rokasgrāmatas, un MTU, kas derēja maršrutētam tunelim, nav pierādījums, ka trunk ceļš darbojas.

Trīs nosacījumi, kas izšķir atbildi

Pirmkārt, vai klienta platforma vispār atbalsta TAP? Android un iOS neatbalsta, un macOS atbalsts ir ierobežots, tāpēc mobilo lietotāju parks izslēdz abus TAP risinājumus neatkarīgi no tā, kā sakārtotas VLAN. Maršrutēta TUN sesija pārnes IP paketes, nevis Ethernet kadrus, un nekāda servera puses VLAN konfigurācija to nemaina. Pārbaudiet parku pirms topoloģijas projektēšanas, jo šo nosacījumu nav iespējams apiet. Tas ir arī nosacījums, kas visbiežāk atklājas pēc komutatora darbu pabeigšanas.

Otrkārt, kas piešķir VLAN? Ja atbilde ir «serveris, pēc tā, kas autentificējās», der komutatora modelis. Ja atbilde ir «esošā komutatoru infrastruktūra ar atzīmēm, kas jau pastāv», jums nepieciešams trunk risinājums.

Treškārt, cik lielai tīkla daļai jābūt sasniedzamai? Komutatora modelis pēc konstrukcijas tur katru klientu vienā VLAN. Trunk risinājums ir tilts, un nepareizi konfigurēts tilts savieno apraides domēnus, kuriem bija jāpaliek šķirtiem.

Izvēles pārbaude

Pievienojiet vienu klientu, kam jābūt atļautajā VLAN, un vienu, kam nevajadzētu, pēc tam pārbaudiet no īstā gala, nevis no paša servera. Sasniedzamība servera pusē pierāda, ka tilts vai komutators pastāv; tā nepierāda, kurā VLAN klients nonāca.

ip -d link show tap0
bridge vlan show

Serverī otrā komanda parāda katra tilta porta VLAN dalību, tostarp to, vai ports ir atzīmēts. Salīdziniet to ar paredzēto piešķīrumu pirms atkļūdošanas jebko virs otrā slāņa.

Pierakstiet, kuru no diviem risinājumiem izmanto izvietojums. Piezīme «VLAN apzinīgs» ir neviennozīmīga, un nākamais inženieris pieņems to, ko iemācījās pirmais. OpenVPN VLAN uzziņadefinē komutatora uzvedību un katra klienta kontekstu, un tas ir īsākais ceļš, lai apstiprinātu, kuru modeli jūs darbināt.