TAP bridge para sa Isang VLAN: ikabit ang subinterface

Ang TAP client na umabot sa LAN bago ang mga VLAN at huminto pagkatapos ay karaniwang may bridge na naglalaman pa rin ng maling interface. Ang pagpapasa ng frame ay hindi nagdadagdag ng VLAN tag, kaya ang frame ng client na walang tag na ipinadala sa pisikal na uplink ay dumarating na walang tag sa isang trunk port at alinman ay itinatapon o napupunta sa native VLAN. Ang pagkakaroon ng subinterface sa kahit saan sa host ay walang binabago sa listahan ng miyembro ng bridge. Iyon ang mito na dapat patayin muna: ang tag ay inilalagay ng interface na nagmamay-ari nito, hindi ng host na mayroon lang nito.

Ang isang extension ng VLAN ay nangangahulugan ng isang domain ng layer 2, at ang bridge ay dapat sumali sa domain na iyon, hindi sa trunk na nagdadala sa kanilang lahat.

Hindi lumilitaw ang tag dahil ini-bridge mo ang trunk

Kumuha ng Linux uplink eno1 na nagdadala ng VLAN 120 patungo sa managed switch. Ang disenyong gumagana para sa isang VLAN ay tap_vpn na naka-bridge sa br_vpn, kung saan ang br_vpn ay naglalaman ng eno1.120 sa halip na eno1. Ang VLAN subinterface ay naglalagay ng tag sa labasan at tinatanggal ito sa pasukan, kaya ang bridge ay nakakakita lamang ng mga frame na walang tag para sa isang VLAN na iyon. Ilagay sa halip ang pisikal na interface sa bridge, at ang parehong mga frame ay lumalabas na walang tag sa isang trunk port, na hindi mo pinlano.

Ang pag-bridge sa trunk na naka-off ang VLAN filtering ay hindi shortcut sa parehong resulta. Ibinibigay nito sa bridge ang bawat VLAN sa kawad na iyon, kasama ang mga hindi dapat makita ng mga client.

Dalawang lehitimong disenyo, isang may-ari ng tag

Ang bridge na may kamalayan sa VLAN ay ang kabilang wastong kaayusan: ang trunk ay pumapasok sa isang bridge port, at ang membership kada port, PVID at mga setting ng tagged egress ang nagpapasya kung aling mga VLAN ang dumadaan. Doon, ang bridge ang may-ari ng pag-tag, at ang pagdaragdag ng VLAN subinterface sa ilalim nito ay maglalagay ng pangalawang may-ari para sa isang gawain. Gumagana ang parehong disenyo; ang mga piraso ng pareho ay hindi. Magpasya kung aling bagay ang naglalagay ng tag bago i-edit ang anumang listahan ng miyembro.

Ang switch port ay dapat sumang-ayon sa alinmang disenyong pipiliin mo. Ang access port na nagdadala ng VLAN nang walang tag ay tumutugma sa pisikal na interface bilang attachment, habang ang trunk port ay tumutugma sa isang tagged subinterface. Ang pagdaragdag ng subinterface sa isang access port na hindi tugma ay walang inaayos.

Ilipat ang address kasama ng membership

Sa disenyong may subinterface, ang address ng host para sa naka-bridge na subnet ay kabilang sa br_vpn, hindi sa alipin na VLAN port kung saan maaaring nanirahan ito noon. Ang pag-iwan nito sa port ay maaaring magmukhang gumagana at pagkatapos ay kakaiba ang kilos, dahil ang bridge ay nagpapasa sa layer 2 habang ang address ay nakaupo sa isang miyembro. Ilipat ito bilang bahagi ng pagbabago ng membership, hindi bilang hiwalay na eksperimento.

Ang paglipat ng address ay maaaring putulin ang daan ng administrasyon. Magtatag ng independiyenteng ruta ng pagbawi, i-save ang umiiral na configuration sa pamamagitan ng sariling network manager ng distribution, at iwasan ang nakikipagkumpitensyang startup script na lalaban dito pagkatapos ng susunod na upgrade.

Ang pag-address sa mga client ay nangangailangan ng parehong pag-iingat. Ang naka-bridge na VPN ay naglalagay ng mga client sa pinalawak na subnet, kaya ang pool ay hindi dapat magsanib sa ibang mga lease o static na pagtatalaga, at ang kaayusang pinaglilingkuran ng DHCP ay dapat ang tunay na inaasahan ng LAN. Ang gumaganang daan sa layer 2 ay walang sinasabi tungkol sa mga doble na address.

Tiyakin ang membership bago sisihin ang mga ruta

Basahin ang kasalukuyang estado, hindi ang nilalayon: ip -d link show dev eno1.120 ay nagpi-print ng VLAN id at ng magulang nito, ip link show master br_vpn ay naglilista ng mga miyembro ng bridge, at bridge vlan show ay nag-uulat ng membership kada port at pagtrato sa labasan. Sa disenyong may subinterface, tiyakin na ang TAP device at VLAN device ang mga miyembro. Sa bridge na may kamalayan sa VLAN, suriin ang mismong patakaran ng port, dahil ang umiiral na bridge ay hindi nagpapatunay kung ano ang pinapayagan nito.

Pagkatapos, subukan ang isang pinapayagang client laban sa isang serbisyo sa VLAN na iyon, tandaan na ang ARP, patakaran ng firewall at daan ng sagot ay hiwalay na usapin sa membership. Kung kumukuha ka ng mga packet, tandaan na ang hardware offload ay maaaring magbago kung saan lumilitaw ang mga VLAN tag sa isang trace. Panatilihing tapat din ang saklaw: ang naka-route na TUN client ay hindi nagiging miyembro ng VLAN sa anumang pagbabago ng bridge, at ang trapiko ng client-sa-client ay hindi pumapalit sa attachment ng host sa VLAN.