TAP-brêge foar ien VLAN: heakje it subynterface oan

In TAP-klant dy't de LAN berikte foar VLAN's en dêrnei stoppe, hat meastentiids in brêge dy't noch it ferkearde ynterface befettet. It trochstjoeren fan frames foeget gjin VLAN-tag ta, sadat in ûntekene klantframe nei de fysike uplink ûntekene oankomt op in trunkpoarte en of fuortgoaid wurdt of yn 'e native VLAN bedarret. Dat it subynterface earne op 'e host bestiet, feroaret neat yn 'e ledelist fan 'e brêge. Dat is de myte dy't earst dea moat: de tag wurdt tapast troch it ynterface dat him besit, net troch de host om't er der ien hat.

Ien VLAN-útbou betsjut ien layer-2-domein, en de brêge moat by dat domein oanslute yn stee fan by de trunk dy't se allegear draacht.

De tag ferskynt net om't jo de trunk brêge hawwe

Nim in Linux-uplink eno1 dy't VLAN 120 nei in behearde switch draacht. It ûntwerp dat foar ien VLAN wurket, is tap_vpn brêge nei br_vpn, wêrby't br_vpn eno1.120 befettet yn stee fan eno1. It VLAN-subynterface past de tag ta by útgong en stript him by yngong, sadat de brêge allinnich ûntekene frames foar dy iene VLAN sjocht. Set ynstee it fysike ynterface yn 'e brêge, en deselde frames ferlitte ûntekene op in trunkpoarte, wat net is wat jo pland hiene.

De trunk brêgje mei VLAN-filtern útskeakele is gjin flugge wei nei itselde resultaat. It jout de brêge elk VLAN op dy tried, ek dy't klanten net hearre te sjen.

Twa legitime ûntwerpen, ien tag-eigner

In VLAN-bewuste brêge is de oare jildige opstelling: de trunk giet in brêgepoarte yn, en lidmaatskip per poarte, PVID en tagde útgongynstellingen beslisse hokker VLAN's trochgeane. Dêr besit de brêge it tagjen, en in VLAN-subynterface derûnder tafoegje soe in twadde eigner foar ien taak ynstallearje. Beide ûntwerpen wurkje; stikken fan beide net. Beslis hokker objekt de tag tapast foar't jo hokker ledelist dan ek bewurkje.

De switchpoarte moat oerienkomme mei it ûntwerp dat jo kieze. In accesspoarte dy't it VLAN ûntekene draacht, past by it fysike ynterface as de oansluting, wylst in trunkpoarte by in tagd subynterface past. In subynterface tafoegje oan in net passende accesspoarte makket neat goed.

Ferpleats it adres mei it lidmaatskip

Yn it subynterface-ûntwerp heart it adres fan 'e host foar it brêge subnet op br_vpn, net op 'e fassade VLAN-poarte dêr't it earder west hawwe kin. It op 'e poarte litte kin lykje te wurkjen en dan frjemd gedrage, om't de brêge op layer 2 trochstjoert wylst it adres op in lid sit. Ferpleats it as part fan 'e lidmaatskipferoaring en net as in apart eksperimint.

It ferpleatsen fan in adres kin it behearspaad ôfsnije. Set in ûnôfhinklike werstelrûte op, bewarje de besteande konfiguraasje fia de eigen netwurkbehearder fan 'e distribúsje, en foarkom in konkurrearjend opstartskript dat der nei de folgjende upgrade tsjin fjochtsje sil.

Klantadressearring freget deselde soarch. In brêge VPN set klanten yn it útwreide subnet, sadat in pool net oerlappe mei oare leases of statyske tawizings, en de opstelling fia DHCP moat dejinge wêze dy't de LAN eins ferwachtet. In wurkjend layer-2-paad seit neat oer dûbele adressen.

Kontrolearje it lidmaatskip foar't jo de rûtes de skuld jouwe

Lês de hjoeddeistige steat yn stee fan 'e bedoelde: ip -d link show dev eno1.120 printsje it VLAN-id en syn âlder, ip link show master br_vpn listet de brêgeleden, en bridge vlan show rapportearret lidmaatskip per poarte en útgongbehanneling. Befêstigje yn it subynterface-ûntwerp dat it TAP-apparaat en it VLAN-apparaat de leden binne. Yn in VLAN-bewuste brêge, kontrolearje it poartebelied sels, om't in besteande brêge net bewissiget wat it talit.

Test dan ien tastiene klant tsjin in tsjinst yn dy VLAN, en betink dat ARP, firewallbelied en it antwurdpaad aparte saken fan lidmaatskip binne. As jo pakketten opfange, tink dan dat hardware-offload feroarje kin wêr't VLAN-tags yn in spoar ferskine. Hâld ek de omfang earlik: in rûte TUN-klant wurdt troch gjin brêgeferoaring in VLAN-lid, en klant-nei-klant-ferkear ferfangt de oansluting fan 'e host oan 'e VLAN net.