En TAP-klient som nådde LAN-et före VLAN och sedan slutade har oftast en brygga som fortfarande innehåller fel gränssnitt. Ramvidarebefordran lägger inte till en VLAN-tagg, så en otaggad klientram som skickas till den fysiska uplänken anländer otaggad på en trunkport och kastas antingen bort eller hamnar i den inbyggda VLAN:en. Att undergränssnittet finns någonstans på värden ändrar ingenting i bryggans medlemslista. Det är myten som måste dödas först: taggen sätts av gränssnittet som äger den, inte av att värden bara har en.

En VLAN-utökning betyder en domän på lager 2, och bryggan måste ansluta till den domänen, inte till trunken som bär alla.

Taggen syns inte för att du bryggade trunken

Ta en Linux-uplänk eno1 som bär VLAN 120 till en hanterad switch. Designen som fungerar för ett VLAN är tap_vpn bryggat till br_vpn, där br_vpn innehåller eno1.120 i stället för eno1. VLAN-undergränssnittet sätter taggen vid utgång och tar bort den vid ingång, så bryggan ser bara otaggade ramar för det enda VLAN:et. Lägg i stället det fysiska gränssnittet i bryggan, och samma ramar lämnar otaggade på en trunkport, vilket du inte planerat.

Att brygga trunken med VLAN-filtrering avstängd är ingen genväg till samma resultat. Det ger bryggan varje VLAN på den ledningen, inklusive de som klienterna inte borde se.

Två legitima designer, en taggägare

En VLAN-medveten brygga är det andra giltiga arrangemanget: trunken går in i en bryggport, och medlemskap per port, PVID och taggade utgångsinställningar avgör vilka VLAN som passerar. Där äger bryggan taggningen, och att lägga ett VLAN-undergränssnitt under den skulle installera en andra ägare för en uppgift. Båda designerna fungerar; fragment av båda gör det inte. Bestäm vilket objekt som sätter taggen innan du redigerar någon medlemslista.

Switchporten måste stämma med vilken design du än väljer. En access-port som bär VLAN:et otaggat passar med det fysiska gränssnittet som anslutning, medan en trunkport passar med ett taggat undergränssnitt. Att lägga ett undergränssnitt till en access-port som inte passar reparerar ingenting.

Flytta adressen tillsammans med medlemskapet

I undergränssnittsdesignen hör värdens adress för det bryggade subnätet till på br_vpn, inte på den slavade VLAN-porten där den kan ha bott tidigare. Att låta den ligga kvar på porten kan se ut att fungera och sedan bete sig märkligt, eftersom bryggan vidarebefordrar på lager 2 medan adressen sitter på en medlem. Flytta den som en del av medlemskapsändringen, inte som ett separat experiment.

Att flytta en adress kan skära av administrationsvägen. Upprätta en oberoende återställningsväg, spara den befintliga konfigurationen via distributionens egen nätverkshanterare och undvik ett konkurrerande startskript som kommer att slåss mot den efter nästa uppgradering.

Klientadressering kräver samma omsorg. En bryggad VPN placerar klienterna i det utökade subnätet, så en pool får inte överlappa andra leasingavtal eller statiska tilldelningar, och ett DHCP-serverat arrangemang måste vara det som LAN:et faktiskt förväntar sig. En fungerande väg på lager 2 säger ingenting om dubbla adresser.

Verifiera medlemskapet innan du skyller på rutter

Läs det aktuella tillståndet i stället för det avsedda: ip -d link show dev eno1.120 skriver ut VLAN-id och dess förälder, ip link show master br_vpn listar bryggans medlemmar, och bridge vlan show rapporterar medlemskap per port och utgångshantering. Bekräfta i undergränssnittsdesignen att TAP-enheten och VLAN-enheten är medlemmarna. Kontrollera själva portpolicyn i en VLAN-medveten brygga, eftersom en brygga som finns inte bevisar vad den tillåter.

Testa sedan en tillåten klient mot en tjänst i det VLAN:et, och kom ihåg att ARP, brandväggspolicy och returväg är separata frågor från medlemskap. Om du fångar paket, notera att hårdvaruoffload kan ändra var VLAN-taggar dyker upp i ett spår. Håll också omfattningen ärlig: en routad TUN-klient blir inte VLAN-medlem av någon bryggändring, och klient-till-klient-trafik ersätter inte värdens anslutning till VLAN:et.

Relaterade artiklar