TAP-brú fyrir eitt VLAN: tengdu undirviðmótið

TAP-biðlari sem náði LAN-inu fyrir VLAN og hætti svo hefur yfirleitt brú sem inniheldur enn rangt viðmót. Rammasending bætir ekki VLAN-merki við, svo ómerktur biðlararammi sem sendur er á líkamlega uplink-ið kemur ómerktur á trunk-port og er annaðhvort hent eða lendir í native VLAN. Það að undirviðmótið sé til einhvers staðar á hýslinum breytir engu um aðildarlista brúarinnar. Þetta er goðsögnin sem á að drepa fyrst: merkið er sett af viðmótinu sem á það, ekki af hýslinum bara af því að það hefur eitt slíkt.

Ein VLAN-lenging þýðir eitt layer-2 lén, og brúin verður að ganga í það lén frekar en trunk-ið sem ber þau öll.

Merkið birtist ekki vegna þess að þú brúaðir trunk-ið

Taktu Linux-uplink eno1 sem ber VLAN 120 að stýrðum rofa. Hönnunin sem virkar fyrir eitt VLAN er tap_vpn brúað yfir á br_vpn, þar sem br_vpn inniheldur eno1.120 í stað eno1. VLAN-undirviðmótið setur merkið á útleið og fjarlægir það á innleið, svo brúin sér aðeins ómerktar ramma fyrir þetta eina VLAN. Settu líkamlega viðmótið í brúna í staðinn, og sömu rammar fara ómerktir út á trunk-porti, sem er ekki það sem þú ætlaðir.

Að brúa trunk-ið með VLAN-síun slökktri er engin flýtileið að sömu niðurstöðu. Það gefur brúnni hvert VLAN á þeim kapli, þar á meðal þau sem biðlarar eiga ekki að sjá.

Tvær lögmætar hannanir, einn merkjaeigandi

VLAN-meðvituð brú er hitt gilda fyrirkomulagið: trunk-ið fer inn á brúarport, og aðild eftir portum, PVID og merktar útleiðarstillingar ákveða hvaða VLAN fara í gegn. Þar á brúin merkinguna, og að bæta VLAN-undirviðmóti undir hana myndi setja annan eiganda fyrir eitt verk. Báðar hannanir virka; brot úr báðum ekki. Ákveddu hvaða hlutur setur merkið áður en þú breytir einhverjum aðildarlista.

Rofaportið verður að passa við hönnunina sem þú velur. Access-port sem ber VLAN-ið ómerkt passar við líkamlega viðmótið sem tenginguna, en trunk-port passar við merkt undirviðmót. Að bæta undirviðmóti við óviðeigandi access-port lagar ekkert.

Færðu vistfangið með aðildinni

Í undirviðmótshönnuninni tilheyrir vistfang hýsilsins fyrir brúaða undirnetið br_vpn, ekki þræluðu VLAN-portinu þar sem það kann að hafa verið áður. Að skilja það eftir á portinu getur virst virka og hegðað sér svo skringilega, því brúin sendir á layer 2 á meðan vistfangið situr á aðila. Færðu það sem hluta af aðildarbreytingunni frekar en sem sérstaka tilraun.

Að færa vistfang getur rofið stjórnunarleiðina. Koma á sjálfstæðri endurheimtarleið, vistaðu núverandi stillingar í gegnum eigin netstjóra dreifingarinnar, og forðastu samkeppnislegt ræsingarskript sem mun berjast við hana eftir næstu uppfærslu.

Biðlaravistföng þurfa sömu umhyggju. Brúuð VPN setur biðlara í stækkað undirnetið, svo hópur má ekki skarast við aðrar leigur eða fastar úthlutanir, og fyrirkomulagið sem DHCP þjónar verður að vera það sem LAN-ið býst raunverulega við. Virk layer-2 leið segir ekkert um tvöföld vistföng.

Staðfestu aðildina áður en þú kennir leiðunum um

Lestu núverandi ástand í stað fyrirhugaðs: ip -d link show dev eno1.120 prentar VLAN-id og foreldri þess, ip link show master br_vpn listar aðila brúarinnar, og bridge vlan show greinir frá aðild eftir portum og meðferð á útleið. Í undirviðmótshönnuninni skaltu staðfesta að TAP-tækið og VLAN-tækið séu aðilarnir. Í VLAN-meðvituðu brú skoðaðu stefnu portsins sjálfs, því tilvera brúar sannar ekki hvað hún leyfir.

Prófaðu svo einn leyfðan biðlara gegn þjónustu í því VLAN, og mundu að ARP, eldveggsstefna og svarleiðin eru aðskilin mál frá aðildinni. Ef þú grípur pakka skaltu hafa í huga að vélbúnaðaroffload getur breytt því hvar VLAN-merki birtast í slóð. Haltu líka umfanginu heiðarlegu: beint TUN-biðlari verður ekki VLAN-aðili með neinni brúarbreytingu, og umferð biðlara á milli biðlara kemur ekki í stað tengingar hýsilsins við VLAN.