En TAP-klient, der nåede LAN'et før VLAN'er og stoppede bagefter, har som regel en bro, der stadig indeholder den forkerte interface. Videresendelse af rammer tilføjer ikke et VLAN-tag, så en utagget klientramme, der sendes til det fysiske uplink, ankommer utagget på en trunkport og bliver enten kasseret eller ender i det native VLAN. At underinterfacet findes et sted på værten ændrer intet ved broens medlemsliste. Det er den myte, der skal aflives først: tagget påsættes af det interface, der ejer det, ikke af værten blot fordi den har et.

Én VLAN-udvidelse betyder ét layer-2-domæne, og broen skal slutte sig til det domæne frem for til trunkforbindelsen, der bærer dem alle.

Tagget dukker ikke op, fordi du brodannede trunkforbindelsen

Tag et Linux-uplink eno1, der bærer VLAN 120 til en administreret switch. Det design, der virker for én VLAN, er tap_vpn brodannet til br_vpn, hvor br_vpn indeholder eno1.120 i stedet for eno1. VLAN-underinterfacet påsætter tagget ved udgang og fjerner det ved indgang, så broen ser kun utaggede rammer for netop den ene VLAN. Sæt i stedet det fysiske interface i broen, og de samme rammer forlader utaggede på en trunkport, hvilket ikke er det, du planlagde.

At brodanne trunkforbindelsen med VLAN-filtrering slået fra er ingen genvej til samme resultat. Det giver broen hver VLAN på den ledning, inklusive dem, klienter ikke har noget at se på.

To legitime design, én tag-ejer

En VLAN-bevidst bro er den anden gyldige ordning: trunkforbindelsen går ind i en broport, og medlemskab pr. port, PVID og tagget udgangsopsætning afgør, hvilke VLAN'er der passerer. Der ejer broen tagningen, og at tilføje et VLAN-underinterface under den ville installere en anden ejer til én opgave. Begge design virker; fragmenter af begge gør ikke. Beslut, hvilket objekt der påsætter tagget, før du redigerer nogen medlemsliste.

Switchporten skal passe til det design, du vælger. En accessport, der bærer VLAN'et utagget, passer med det fysiske interface som tilknytning, mens en trunkport passer med et tagget underinterface. At tilføje et underinterface til en accessport, der ikke passer, reparerer intet.

Flyt adressen sammen med medlemskabet

I underinterface-designet hører værtens adresse til det brodannede subnet på br_vpn, ikke på den slavegjorte VLAN-port, hvor den måske lå før. At lade den blive på porten kan se ud til at virke og derefter opføre sig mærkeligt, fordi broen videresender på layer 2, mens adressen sidder på et medlem. Flyt den som en del af medlemskabsændringen frem for som et særskilt eksperiment.

At flytte en adresse kan afskære administrationsvejen. Etabler en uafhængig gendannelsesrute, gem den eksisterende konfiguration gennem distributionens egen netværksadministrator, og undgå et konkurrerende opstartsscript, der vil bekæmpe den efter næste opgradering.

Klientadressering kræver samme omhu. En brodannet VPN placerer klienter i det udvidede subnet, så en pulje må ikke overlappe andre leases eller statiske tildelinger, og en DHCP-betjent ordning skal være den, LAN'et faktisk forventer. En fungerende layer-2-vej siger intet om dublerede adresser.

Bekræft medlemskabet, før du skylder på ruterne

Læs den aktuelle tilstand i stedet for den tilsigtede: ip -d link show dev eno1.120 udskriver VLAN-id og dets forælder, ip link show master br_vpn viser broens medlemmer, og bridge vlan show rapporterer medlemskab pr. port og udgangsbehandling. I underinterface-designet skal du bekræfte, at TAP-enheden og VLAN-enheden er medlemmerne. I en VLAN-bevidst bro skal du kontrollere selve portpolitikken, fordi en eksisterende bro ikke beviser, hvad den tillader.

Test derefter én tilladt klient mod en tjeneste i den VLAN, og husk, at ARP, firewallpolitik og svarvejen er særskilte forhold i forhold til medlemskabet. Hvis du opfanger pakker, så bemærk, at hardware-offload kan ændre, hvor VLAN-tags dukker op i et spor. Hold også omfanget ærligt: en routet TUN-klient bliver ikke VLAN-medlem af nogen broændring, og klient-til-klient-trafik erstatter ikke værtens tilknytning til VLAN'et.

Relaterede artikler