Most TAP dla jednego VLAN: podłącz podinterfejs

Klient TAP, który dotarł do LAN przed VLAN-ami i potem przestał, zwykle ma most nadal zawierający niewłaściwy interfejs. Przekazywanie ramek nie dodaje tagu VLAN, więc nieotagowana ramka klienta wysłana do fizycznego uplinku dociera bez tagu na port trunka i jest albo odrzucana, albo trafia do natywnego VLAN. To, że podinterfejs istnieje gdzieś na hoście, niczego nie zmienia w liście członków mostu. To mit, który trzeba zabić najpierw: tag nakłada interfejs, który go posiada, a nie host, który po prostu go ma.

Jedno rozszerzenie VLAN oznacza jedną domenę warstwy 2, a most musi dołączyć do tej domeny, a nie do trunka przenoszącego je wszystkie.

Tag się nie pojawia, bo zmostkowałeś trunk

Weź uplink Linuksa eno1 przenoszący VLAN 120 do zarządzanego przełącznika. Projekt, który działa dla jednego VLAN, to tap_vpn zmostkowany z br_vpn, gdzie br_vpn zawiera eno1.120, a nie eno1. Podinterfejs VLAN nakłada tag na wyjściu i zdejmuje go na wejściu, więc most widzi tylko nieotagowane ramki dla tego jednego VLAN. Zamiast tego włóż fizyczny interfejs do mostu, a te same ramki wyjdą bez tagu na porcie trunka, co nie było planowane.

Mostkowanie trunka przy wyłączonym filtrowaniu VLAN nie jest skrótem do tego samego wyniku. Oddaje mostowi każdy VLAN na tym przewodzie, także te, których klienci nie powinni widzieć.

Dwa legalne projekty, jeden właściciel tagu

Most świadomy VLAN to inny poprawny układ: trunk wchodzi do portu mostu, a przynależność na port, PVID i ustawienia otagowanego wyjścia decydują, które VLAN przechodzą. Tam most posiada tagowanie, a dodanie pod nim podinterfejsu VLAN zainstalowałoby drugiego właściciela dla jednego zadania. Oba projekty działają; fragmenty obu nie. Zdecyduj, który obiekt nakłada tag, zanim zmienisz jakąkolwiek listę członków.

Port przełącznika musi zgadzać się z wybranym projektem. Port access przenoszący VLAN bez tagu pasuje do fizycznego interfejsu jako przyłącza, natomiast port trunka pasuje do otagowanego podinterfejsu. Dodanie podinterfejsu do niedopasowanego portu access niczego nie naprawia.

Przenieś adres razem z przynależnością

W projekcie z podinterfejsem adres hosta dla zmostkowanej podsieci należy umieścić na br_vpn, a nie na podporządkowanym porcie VLAN, gdzie mógł wcześniej mieszkać. Pozostawienie go na porcie może wyglądać na działające, a potem zachowywać się dziwnie, bo most przekazuje w warstwie 2, podczas gdy adres siedzi na członku. Przenieś go jako część zmiany przynależności, a nie jako osobny eksperyment.

Przeniesienie adresu może odciąć ścieżkę administracyjną. Ustanów niezależną trasę odzyskiwania, zapisz istniejącą konfigurację przez własny menedżer sieci dystrybucji i unikaj konkurencyjnego skryptu startowego, który będzie z nim walczył po następnej aktualizacji.

Adresowanie klientów wymaga tej samej staranności. Zmostkowany VPN umieszcza klientów w rozszerzonej podsieci, więc pula nie może nakładać się na inne dzierżawy ani przypisania statyczne, a układ obsługiwany przez DHCP musi być tym, którego LAN naprawdę oczekuje. Działająca ścieżka warstwy 2 nic nie mówi o zduplikowanych adresach.

Sprawdź przynależność, zanim obwinisz trasy

Czytaj stan bieżący, a nie zamierzony: ip -d link show dev eno1.120 wypisuje id VLAN i jego rodzica, ip link show master br_vpn wymienia członków mostu, a bridge vlan show raportuje przynależność na port i obsługę wyjścia. W projekcie z podinterfejsem potwierdź, że urządzenie TAP i urządzenie VLAN są członkami. W moście świadomym VLAN sprawdź samą politykę portu, bo istniejący most nie dowodzi, co dopuszcza.

Następnie przetestuj jednego dozwolonego klienta wobec usługi w tym VLAN, pamiętając, że ARP, polityka zapory i ścieżka odpowiedzi to osobne kwestie od przynależności. Jeśli przechwytujesz pakiety, pamiętaj, że offload sprzętowy może zmienić, gdzie tagi VLAN pojawiają się w śladzie. Utrzymaj też uczciwy zakres: trasowany klient TUN nie staje się członkiem VLAN przez żadną zmianę mostu, a ruch klient-klient nie zastępuje przyłącza hosta do VLAN.