TAP-brug vir een VLAN: koppel die subkoppelvlak

'n TAP-kliënt wat die LAN voor VLAN's bereik het en daarna opgehou het, het gewoonlik 'n brug wat steeds die verkeerde koppelvlak bevat. Raamverstuur voeg nie 'n VLAN-merker by nie, so 'n ongemerkte kliëntraam wat na die fisiese opvoerlink gestuur word, kom ongemerk op 'n trunk-poort aan en word óf weggegooi óf beland in die native VLAN. Die subkoppelvlak wat iewers op die gasheer bestaan, verander niks aan die brug se ledelys nie. Dit is die mite wat eerste doodgemaak moet word: die merker word deur die koppelvlak toegepas wat dit besit, nie deur die gasheer bloot omdat hy een het nie.

Een VLAN-uitbreiding beteken een laag-2-domein, en die brug moet by daardie domein aansluit eerder as by die trunk wat almal dra.

Die merker verskyn nie omdat jy die trunk oorbrug het nie

Neem 'n Linux-opvoerlink eno1 wat VLAN 120 na 'n bestuurde skakelaar dra. Die ontwerp wat vir 'n enkele VLAN werk, is tap_vpn wat aan br_vpn oorbrug is, met br_vpn wat eno1.120 bevat eerder as eno1. Die VLAN-subkoppelvlak pas die merker op uitgang toe en stroop dit op ingang, so die brug sien net ooit ongemerkte rame vir daardie een VLAN. Sit eerder die fisiese koppelvlak in die brug, en dieselfde rame verlaat ongemerk op 'n trunk-poort, wat nie is wat jy beplan het nie.

Om die trunk te oorbrug met VLAN-filtering afgeskakel is geen kortpad na dieselfde resultaat nie. Dit gee die brug elke VLAN op daardie draad, insluitend dié wat kliënte nie moet sien nie.

Twee wettige ontwerpe, een merker-eienaar

'n VLAN-bewuste brug is die ander geldige reëling: die trunk gaan 'n brugpoort binne, en lidmaatskap per poort, PVID en gemerkte uitgang-instellings bepaal watter VLAN's deurgaan. Daar besit die brug die merkwerk, en om 'n VLAN-subkoppelvlak daaronder by te voeg, sou 'n tweede eienaar vir een taak installeer. Beide ontwerpe werk; fragmente van beide nie. Besluit watter objek die merker toepas voordat jy enige ledelys wysig.

Die skakelaarpoort moet saamstem met watter ontwerp jy ook al kies. 'n Toegangspoort wat die VLAN ongemerk dra, pas by die fisiese koppelvlak as die aanhegting, terwyl 'n trunk-poort by 'n gemerkte subkoppelvlak pas. Om 'n subkoppelvlak by 'n wanpasende toegangspoort te voeg, maak niks reg nie.

Skuif die adres saam met die lidmaatskap

In die subkoppelvlak-ontwerp hoort die gasheer se adres vir die oorbrugde subnet op br_vpn, nie op die ingeslote VLAN-poort waar dit voorheen kon gewees het nie. Om dit op die poort te laat, kan werk lyk en dan vreemd optree, want die brug stuur op laag 2 terwyl die adres op 'n lid sit. Skuif dit as deel van die lidmaatskapverandering eerder as as 'n aparte eksperiment.

Om 'n adres te skuif kan die administrasiepad afsny. Vestig 'n onafhanklike herstelroete, stoor die bestaande konfigurasie deur die distribusie se eie netwerkbestuurder, en vermy 'n mededingende opstartskrip wat dit ná die volgende opgradering sal beveg.

Kliëntadressering het dieselfde sorg nodig. 'n Oorbrugde VPN plaas kliënte in die uitgebreide subnet, so 'n poel mag nie ander huurkontrakte of statiese toekennings oorvleuel nie, en 'n DHCP-bediende reëling moet die een wees wat die LAN werklik verwag. 'n Werkende laag-2-pad sê niks oor duplikaatadresse nie.

Verifieer lidmaatskap voordat jy roetes blameer

Lees die huidige toestand eerder as die beoogde een: ip -d link show dev eno1.120 druk die VLAN-id en sy ouer uit, ip link show master br_vpn lys bruglede, en bridge vlan show rapporteer lidmaatskap per poort en uitgangsbehandeling. Bevestig in die subkoppelvlak-ontwerp dat die TAP-toestel en die VLAN-toestel die lede is. Kyk in 'n VLAN-bewuste brug na die poortbeleid self, want 'n brug wat bestaan, bewys nie wat dit toelaat nie.

Toets dan een toegelate kliënt teen 'n diens in daardie VLAN, en onthou dat ARP, brandmuurbeleid en die antwoordpad aparte sake van lidmaatskap is. As jy pakkette vasvang, let op dat hardeware-offlaai kan verander waar VLAN-merkers in 'n spoor verskyn. Hou ook die omvang eerlik: 'n gerouteerde TUN-kliënt word nie deur enige brugverandering 'n VLAN-lid nie, en kliënt-tot-kliënt-verkeer vervang nie die gasheer-tot-VLAN-aanhegting nie.