TAP most pro jednu VLAN: připojte podrozhraní

TAP klient, který se do LAN dostal před VLAN a potom přestal, má obvykle most, který stále obsahuje špatné rozhraní. Přeposílání rámců nepřidává značku VLAN, takže neznačkovaný klientský rámec odeslaný na fyzický uplink dorazí neznačkovaný na trunk port a buď se zahodí, nebo skončí v nativní VLAN. Existence podrozhraní někde na hostiteli nic nemění na seznamu členů mostu. To je mýtus, který je třeba zabít jako první: značku aplikuje rozhraní, které ji vlastní, ne hostitel jen proto, že nějaké má.

Jedno rozšíření VLAN znamená jednu doménu layer-2 a most se musí připojit k této doméně, ne k trunku, který je nese všechny.

Značka se neobjeví, protože jste přemostili trunk

Vezměte Linux uplink eno1, který nese VLAN 120 ke spravovanému přepínači. Návrh, který funguje pro jednu VLAN, je tap_vpn přemostěný na br_vpn, přičemž br_vpn obsahuje eno1.120 místo eno1. Podrozhraní VLAN aplikuje značku na výstupu a odstraní ji na vstupu, takže most vidí jen neznačkované rámce pro tuto jednu VLAN. Dejte do mostu místo toho fyzické rozhraní a stejné rámce odejdou neznačkované na trunk portu, což není to, co jste plánovali.

Přemostění trunku s vypnutým filtrováním VLAN není zkratkou ke stejnému výsledku. Předá mostu každou VLAN na tom kabelu, včetně těch, které klienti nemají vidět.

Dva legitimní návrhy, jeden vlastník značky

Most s vědomím VLAN je druhé platné uspořádání: trunk vstupuje do portu mostu a členství na portu, PVID a nastavení značkovaného výstupu rozhodují, které VLAN projdou. Tam značkování vlastní most a přidání podrozhraní VLAN pod něj by nainstalovalo druhého vlastníka pro jednu práci. Oba návrhy fungují; jejich směs ne. Rozhodněte, který objekt značku aplikuje, než začnete editovat jakýkoli seznam členů.

Port switche musí odpovídat zvolenému návrhu. Access port nesoucí VLAN neznačkovaně se páruje s fyzickým rozhraním jako připojení, kdežto trunk port se páruje se značkovaným podrozhraním. Přidání podrozhraní k neodpovídajícímu access portu nic nespraví.

Přesuňte adresu spolu s členstvím

V návrhu s podrozhraním adresa hostitele pro přemostěnou podsíť patří na br_vpn, ne na podřízený VLAN port, kde mohla být dříve. Ponechat ji na portu může vypadat funkčně a pak se chovat podivně, protože most přeposílá na layer 2, zatímco adresa sedí na členu. Přesuňte ji jako součást změny členství, ne jako samostatný experiment.

Přesun adresy může odříznout administrativní cestu. Zřiďte nezávislou cestu pro obnovu, uložte stávající konfiguraci přes vlastního správce sítě distribuce a vyhněte se konkurenčnímu startovnímu skriptu, který se s ním po příští aktualizaci popere.

Adresování klientů potřebuje stejnou péči. Přemostěná VPN umisťuje klienty do rozšířené podsítě, takže fond se nesmí překrývat s jinými lease ani statickými přiřazeními a uspořádání obsluhované DHCP musí být to, které LAN skutečně očekává. Fungující cesta layer-2 nic neříká o duplicitních adresách.

Ověřte členství, než obviníte routy

Čtěte aktuální stav, ne zamýšlený: ip -d link show dev eno1.120 vypíše id VLAN a jeho rodiče, ip link show master br_vpn vypíše členy mostu a bridge vlan show hlásí členství na portech a zacházení na výstupu. V návrhu s podrozhraním ověřte, že členy jsou zařízení TAP a zařízení VLAN. U mostu s vědomím VLAN zkontrolujte samotnou politiku portu, protože existence mostu nedokazuje, co povoluje.

Potom otestujte jednoho povoleného klienta proti službě v té VLAN, s vědomím, že ARP, politika firewallu a cesta odpovědi jsou od členství oddělené záležitosti. Pokud zachytáváte pakety, pamatujte, že hardwarový offload může změnit, kde se značky VLAN v trasování objeví. Udržte také rozsah poctivý: routovaný klient TUN se žádnou změnou mostu nestane členem VLAN a provoz klient-klient nenahrazuje připojení hostitele k VLAN.