TAP-ponto por unu VLAN: aligu la subinterfacon

TAP-kliento, kiu atingis la LANon antaŭ la VLANoj kaj poste ĉesis, kutime havas ponton, kiu ankoraŭ enhavas la malĝustan interfacon. Kadropluado ne aldonas VLAN-etikedon, do neetikedita klientokadro sendita al la fizika uplinko alvenas neetikedita ĉe trunk-pordo kaj aŭ estas forĵetata, aŭ finiĝas en la denaska VLAN. Tio, ke la subinterfaco ekzistas ie en la hosto, ŝanĝas nenion en la membrolisto de la ponto. Ĝuste tiun miton oni unue mortigu: la etikedon aplikas la interfaco, kiu posedas ĝin, ne la hosto nur ĉar ĝi havas tian.

Unu VLAN-etendaĵo signifas unu layer-2-domajnon, kaj la ponto devas aliĝi al tiu domajno, ne al la trunko, kiu portas ĉiujn.

La etikedo ne aperas ĉar vi pontigis la trunkon

Prenu Linux-uplinkon eno1, kiu portas VLAN 120 al administrata ŝaltilo. La dizajno, kiu funkcias por unu VLAN, estas tap_vpn pontigita al br_vpn, kie br_vpn enhavas eno1.120 anstataŭ eno1. La VLAN-subinterfaco aplikas la etikedon ĉe eliro kaj forigas ĝin ĉe eniro, do la ponto vidas nur neetikeditajn kadrojn por tiu unu VLAN. Metu anstataŭe la fizikan interfacon en la ponton, kaj la samaj kadroj eliras neetikeditaj ĉe trunk-pordo, kio ne estas tio, kion vi planis.

Pontigi la trunkon kun VLAN-filtrado malŝaltita ne estas fuŝvojo al la sama rezulto. Ĝi donas al la ponto ĉiun VLANon sur tiu drato, inkluzive de tiuj, kiujn klientoj ne devus vidi.

Du legitimaj dizajnoj, unu etikeda posedanto

VLAN-konscia ponto estas la alia valida aranĝo: la trunko eniras pontan pordon, kaj membroeco laŭ pordo, PVID kaj etikeditaj eliraj agordoj decidas, kiuj VLANoj pasas. Tie la ponto posedas la etikedadon, kaj aldoni VLAN-subinterfacon sub ĝi instalus duan posedanton por unu tasko. Ambaŭ dizajnoj funkcias; fragmentoj de ambaŭ ne. Decidu, kiu objekto aplikas la etikedon, antaŭ ol redakti ajnan membroliston.

La ŝaltila pordo devas akordi kun la dizajno, kiun vi elektas. Access-pordo portanta la VLANon neetikeditan pariĝas kun la fizika interfaco kiel la ligilo, dum trunk-pordo pariĝas kun etikedita subinterfaco. Aldoni subinterfacon al nekonforma access-pordo riparas nenion.

Movu la adreson kune kun la membreco

En la subinterfaca dizajno, la adreso de la hosto por la pontigita subreto apartenas al br_vpn, ne al la sklavigita VLAN-pordo, kie ĝi eble antaŭe loĝis. Lasi ĝin sur la pordo povas ŝajni funkcii kaj poste konduti strange, ĉar la ponto plusendas ĉe layer 2 dum la adreso sidas sur membro. Movu ĝin kiel parton de la membroeca ŝanĝo, ne kiel apartan eksperimenton.

Movi adreson povas fortranĉi la administran vojon. Starigu sendependan reakiran vojon, konservu la ekzistantan agordon per la propra retadministrilo de la distribuo, kaj evitu konkurencan startan skripton, kiu luktos kontraŭ ĝi post la sekva ĝisdatigo.

Klienta adresado bezonas la saman zorgon. Pontigita VPN metas klientojn en la etenditan subreton, do naĝejo ne rajtas interkovriĝi kun aliaj luoj aŭ statikaj atribuoj, kaj la aranĝo servita per DHCP devas esti tiu, kiun la LAN vere atendas. Funkcianta layer-2-vojo diras nenion pri duoblaj adresoj.

Kontrolu la membrecon antaŭ ol kulpigi la vojojn

Legu la nunan staton anstataŭ la celatan: ip -d link show dev eno1.120 printas la VLAN-id kaj ĝian gepatro, ip link show master br_vpn listigas la membrojn de la ponto, kaj bridge vlan show raportas membrecon laŭ pordo kaj eliran traktadon. En la subinterfaca dizajno, konfirmu, ke la TAP-aparato kaj la VLAN-aparato estas la membroj. En VLAN-konscia ponto, kontrolu la pordan politikon mem, ĉar ekzistanta ponto ne pruvas, kion ĝi permesas.

Poste testu unu permesitan klienton kontraŭ servo en tiu VLANo, memorante, ke ARP, fajroŝirma politiko kaj la responda vojo estas apartaj aferoj de la membreco. Se vi kaptas pakojn, notu, ke aparatara malŝarĝo povas ŝanĝi, kie VLAN-etikedoj aperas en spuro. Tenu ankaŭ la amplekson honesta: enkursigita TUN-kliento ne fariĝas VLAN-membro per ia ponta ŝanĝo, kaj kliento-al-klienta trafiko ne anstataŭas la ligon de la hosto al la VLANo.