Klientų VLAN ar žymėtas trunk: pasirinkite tinkamą OpenVPN režimą

Ateina dvi beveik vienodai suformuluotos užklausos: įdėti kiekvieną VPN klientą į pasirinktą VLAN arba perkelti esamą VLAN trunk per VPN. Tai du skirtingi produktai. Įtaisytasis OpenVPN režimas, suprantantis VLAN, yra komutatoriaus modelis pirmajai užklausai ir nėra skaidraus žymų perdavimo sinonimas. Netinkamas pasirinkimas sukuria sprendimą, kuris atrodo sukonfigūruotas, bet tyliai išmeta tuos kadrus, kurie jums buvo svarbūs.

Ką iš tikrųjų sukuria VLAN suprantantis režimas

Kai vlan-tagging įjungtas tik serverio TAP diegime, demonas modeliuoja savo TAP įrenginį ir kiekvieną prijungtą klientą kaip vidinio komutatoriaus prievadus. Klientų prievadai yra be žymos, o jų VLAN susiejimas nustatomas serveryje per kiekvieno kliento vlan-pvid kontekstą, o ne per tai, ką siunčia klientas. Tai ir yra visa modelio esmė: narystė yra serverio pusės sprendimas apie autentifikuotą partnerį. Niekas kliento profilyje neturi žinoti, kuriam VLAN jis priklauso.

Serverio TAP pusė gauna savo žymėtų arba nežymėtų kadrų priėmimo politiką per vlan-accept. Persiuntimas tame komutatoriuje vyksta tik tarp atitinkančių VID, įskaitant atvejus, kai nustatytas client-to-client, todėl du klientai skirtinguose VLAN negali pasiekti vienas kito per serverį, nors abu prie jo prijungti.

Šis modelis yra prieigos prievado modelis. Iš kliento išeinantys kadrai yra be žymos, o susiejimą primeta serveris pagal tapatybę. Prašyti nešiojamojo kompiuterio pačiam žymėti savo srautą reiškia prašyti kito sprendimo.

Priskyrimai turi sekti autentifikuotą kliento tapatybę, o ne vertę, kurią klientas siūlo apie save. Praleistas priskyrimas taip pat nėra karantino būsena: klientas patenka į numatytąjį PVID, todėl trūkstamas ccd įrašas yra tylus politikos sprendimas, o ne neutralus.

Ko vietoj to reikalauja skaidrus trunk

Jau pažymėtų kadrų perkėlimas nuo galo iki galo prasideda išjungus VLAN suprantantį apdorojimą. Komutatoriaus modelis ir žymų išsaugojimas yra alternatyvos, o įjungus abu viena funkcija prašoma atlikti kitos darbą.

Išjungimas yra tik pradžia. Tiltas kiekviename gale ir fiziniai komutatoriaus prievadai turi sutarti, kurie VLAN leidžiami, kuri žyma yra vietinė ir kaip elgiamasi su nežymėtais kadrais. Neriboto trunk išplėtimas atskleidžia daug daugiau transliacijos sričių nei tos dvi, kurias norėjote sujungti.

Kadro dydžiui reikia atskiro biudžeto. Žymėtas Ethernet kadras su inkapsuliavimu yra didesnis nei naudingosios apkrovos skaičius, kurį žmonės nusirašo iš vadovo, o MTU, tinkamas maršrutizuotam tuneliui, neįrodo, kad trunk kelias veikia.

Trys sąlygos, lemiančios atsakymą

Pirma, ar kliento platforma apskritai palaiko TAP? Android ir iOS nepalaiko, o macOS palaikymas ribotas, todėl mobiliųjų naudotojų parkas atmeta abu TAP sprendimus, nesvarbu, kaip išdėstyti VLAN. Maršrutizuota TUN sesija perduoda IP paketus, o ne Ethernet kadrus, ir jokia serverio pusės VLAN konfigūracija to nepakeis. Patikrinkite parką prieš projektuodami topologiją, nes šios sąlygos apeiti neįmanoma. Tai ir sąlyga, kuri dažniausiai paaiškėja jau baigus komutatoriaus darbus.

Antra, kas skiria VLAN? Jei atsakymas «serveris, pagal tai, kas autentifikavosi», tinka komutatoriaus modelis. Jei atsakymas «esama komutatorių infrastruktūra su žymomis, kurios jau yra», jums reikia trunk sprendimo.

Trečia, kokia tinklo dalis turi būti pasiekiama? Komutatoriaus modelis pagal konstrukciją laiko kiekvieną klientą viename VLAN. Trunk sprendimas yra tiltas, o neteisingai sukonfigūruotas tiltas sujungia transliacijos sritis, kurios turėjo likti atskirtos.

Pasirinkimo patikrinimas

Prijunkite vieną klientą, kuris turi būti leidžiamame VLAN, ir vieną, kuris neturi, tada tikrinkite iš tikrojo galinio taško, o ne iš paties serverio. Pasiekiamumas serverio pusėje įrodo, kad tiltas ar komutatorius egzistuoja; jis neįrodo, į kurį VLAN pateko klientas.

ip -d link show tap0
bridge vlan show

Serveryje antroji komanda rodo kiekvieno tilto prievado VLAN narystę, įskaitant tai, ar prievadas pažymėtas. Palyginkite tai su numatytu priskyrimu prieš derindami ką nors aukščiau antrojo sluoksnio.

Užsirašykite, kurį iš dviejų sprendimų naudoja diegimas. Užrašas «suprantantis VLAN» yra dviprasmis, o kitas inžinierius laikys tuo, kurį išmoko pirmą. OpenVPN VLAN žinynasapibrėžia komutatoriaus elgesį ir kiekvieno kliento kontekstą, ir tai trumpiausias kelias patvirtinti, kurį modelį naudojate.