Mga VLAN ng kliyente o isang naka-tag na trunk: piliin ang tamang OpenVPN mode

Dalawang kahilingan ang dumarating na halos magkapareho ang pananalita: ilagay ang bawat kliyente ng VPN sa piniling VLAN, o dalhin ang umiiral na trunk ng VLAN sa ibabaw ng VPN. Dalawang magkaibang produkto ito. Ang built-in na mode ng OpenVPN na may kamalayan sa VLAN ay modelo ng switch para sa unang kahilingan, at hindi ito kasingkahulugan ng transparent na transport ng tag. Ang maling pagpili ay gumagawa ng disenyong mukhang naka-configure at tahimik na itinatapon ang mga frame na mahalaga sa iyo.

Ano ang aktwal na itinatayo ng mode na may kamalayan sa VLAN

Kapag naka-enable ang vlan-tagging sa isang deployment ng TAP para sa server lamang, ginagaya ng daemon ang TAP device nito at ang bawat konektadong kliyente bilang mga port ng panloob na switch. Walang tag ang mga port ng kliyente, at ang kanilang kaugnayan sa VLAN ay itinatakda sa server sa pamamagitan ng kontekstong vlan-pvid bawat kliyente, hindi ng anumang ipinapadala ng kliyente. Iyon ang buong punto ng modelo: ang pagiging miyembro ay desisyon sa panig ng server tungkol sa isang authenticated na kapareha. Wala sa profile ng kliyente ang kailangang malaman kung aling VLAN ito kabilang.

Ang panig ng TAP ng server ay may sariling patakaran sa pagtanggap ng naka-tag o walang tag na frame sa pamamagitan ng vlan-accept. Ang pagpapasa sa loob ng switch na iyon ay nangyayari lamang sa pagitan ng magkatugmang VID, kabilang kapag nakatakda ang client-to-client, kaya dalawang kliyente sa magkaibang VLAN ay hindi maaaring mag-abot sa isa't isa sa pamamagitan ng server kahit pareho silang konektado dito.

Ang modelong iyon ay modelo ng access port. Walang tag ang mga frame na lumalabas mula sa kliyente, at ipinapataw ng server ang kaugnayan batay sa pagkakakilanlan. Ang hilingin sa laptop na i-tag ang sarili nitong traffic ay humihingi ng ibang disenyo.

Dapat sundin ng mga pagtatalaga ang authenticated na pagkakakilanlan ng kliyente, hindi ang halagang iniaalok ng kliyente tungkol sa sarili nito. Ang tinanggal na pagtatalaga ay hindi rin estado ng quarantine: napupunta ang kliyente sa default na PVID, kaya ang nawawalang entry ng ccd ay tahimik na desisyon sa patakaran, hindi neutral.

Ano ang kailangan ng transparent na trunk sa halip

Ang pagdadala ng mga frame na may tag na mula simula hanggang dulo ay nagsisimula sa pag-off ng pagpoprosesong may kamalayan sa VLAN. Ang modelo ng switch at ang pagpapanatili ng tag ay magkaiba, at ang pagpapagana ng pareho ay humihiling sa isang tampok na gawin ang trabaho ng isa.

Ang pag-off ay simula pa lamang. Ang tulay sa bawat dulo at ang mga pisikal na port ng switch ay dapat magkasundo kung aling VLAN ang pinapayagan, aling tag ang native, at paano tinatrato ang mga frame na walang tag. Ang pagpapalawak ng walang limitasyong trunk ay naglalantad ng higit pang broadcast domain kaysa sa dalawang nais mong ikonekta.

Ang laki ng frame ay nangangailangan ng sariling badyet. Ang naka-tag na Ethernet frame kasama ang encapsulation ay mas malaki kaysa sa figure ng payload na kinokopya ng mga tao mula sa gabay, at ang MTU na umaangkop sa isang routed tunnel ay hindi patunay na gumagana ang isang trunk path.

Tatlong kundisyon na nagpapasya sa sagot

Una, sinusuportahan ba ng platform ng kliyente ang TAP? Hindi ng Android at iOS, at limitado ang suporta ng macOS, kaya ang isang fleet ng mobile na user ay tinatanggihan ang alinman sa dalawang disenyong TAP, gaano man inayos ang mga VLAN. Ang routed na TUN session ay nagdadala ng IP packet, hindi Ethernet frame, at walang configuration ng VLAN sa server ang makakabago niyon. Suriin ang fleet bago idisenyo ang topology, dahil ito ang kundisyong hindi maiiwasan. Ito rin ang kundisyong kadalasang natutuklasan pagkatapos matapos ang gawain sa switch.

Pangalawa, sino ang nagtatalaga ng VLAN? Kung ang sagot ay «ang server, batay sa kung sino ang nagpatunay ng pagkakakilanlan», bagay ang modelo ng switch. Kung ang sagot ay «ang umiiral na imprastraktura ng switch, na may mga tag na umiiral na», kailangan mo ang disenyo ng trunk.

Pangatlo, gaano kalaki ng network ang dapat maabot? Pinapanatili ng modelo ng switch ang bawat kliyente sa isang VLAN ayon sa pagkakagawa. Ang disenyo ng trunk ay tulay, at ang maling naka-configure na tulay ay nag-uugnay ng mga broadcast domain na dapat sanang manatiling hiwalay.

Pagsubok sa piniling paraan

Ikonekta ang isang kliyente na dapat nasa pinapayagang VLAN at isa na hindi dapat, pagkatapos ay subukan mula sa tunay na dulo at hindi mula sa server mismo. Ang maabot mula sa panig ng server ay nagpapatunay na may tulay o switch; hindi nito pinapatunayan kung aling VLAN napunta ang kliyente.

ip -d link show tap0
bridge vlan show

Sa server, ipinapakita ng ikalawang utos ang pagiging miyembro sa VLAN ng bawat port ng tulay, kabilang kung naka-tag ang port. Ihambing iyon sa pagtatalagang nilalayon mo bago mag-debug ng anuman sa itaas ng layer two.

Itala kung alin sa dalawang disenyo ang ginagamit ng deployment. Ang tala na nagsasabing «may kamalayan sa VLAN» ay malabo, at ipagpapalagay ng susunod na inhinyero ang una niyang natutunan. Ang sanggunian ng VLAN ng OpenVPNay tumutukoy sa pag-uugali ng switch at sa konteksto bawat kliyente, at ito ang pinakamaikling landas upang kumpirmahin kung aling modelo ang pinapatakbo mo.