Bridge TAP pentru un singur VLAN: atașează subinterfața

Un client TAP care ajungea în LAN înainte de VLAN-uri și s-a oprit după aceea are de obicei un bridge care conține încă interfața greșită. Forwardarea cadrelor nu adaugă un tag VLAN, așa că un cadru de client fără tag trimis către uplink-ul fizic ajunge fără tag pe un port trunk și este fie aruncat, fie ajunge în VLAN-ul nativ. Faptul că subinterfața există undeva pe host nu schimbă nimic din lista de membri a bridge-ului. Acesta este mitul de ucis mai întâi: tag-ul este aplicat de interfața care îl deține, nu de hostul care pur și simplu are una.

O extensie VLAN înseamnă un domeniu de nivel 2, iar bridge-ul trebuie să intre în acel domeniu, nu în trunk-ul care le cară pe toate.

Tag-ul nu apare pentru că ai pus trunk-ul în bridge

Ia un uplink Linux eno1 care cară VLAN 120 către un switch administrat. Designul care funcționează pentru un singur VLAN este tap_vpn pus în bridge cu br_vpn, cu br_vpn conținând eno1.120 în loc de eno1. Subinterfața VLAN aplică tag-ul la ieșire și îl scoate la intrare, așa că bridge-ul vede doar cadre fără tag pentru acel VLAN. Pune în schimb interfața fizică în bridge, iar aceleași cadre ies fără tag pe un port trunk, ceea ce nu ai plănuit.

Punerea trunk-ului în bridge cu filtrarea VLAN oprită nu este o scurtătură la același rezultat. Îi dă bridge-ului fiecare VLAN de pe acel cablu, inclusiv pe cele pe care clienții nu ar trebui să le vadă.

Două designuri legitime, un singur proprietar al tag-ului

Un bridge conștient de VLAN este cealaltă aranjare validă: trunk-ul intră într-un port al bridge-ului, iar apartenența pe port, PVID-ul și setările de ieșire cu tag decid ce VLAN-uri trec. Acolo bridge-ul deține tag-ul, iar adăugarea unei subinterfețe VLAN dedesubt ar instala un al doilea proprietar pentru o singură sarcină. Ambele designuri funcționează; fragmente din ambele nu. Decide ce obiect aplică tag-ul înainte de a edita vreo listă de membri.

Portul switch-ului trebuie să fie de acord cu orice design alegi. Un port access care cară VLAN-ul fără tag se potrivește cu interfața fizică drept atașament, în timp ce un port trunk se potrivește cu o subinterfață cu tag. Adăugarea unei subinterfețe la un port access nepotrivit nu repară nimic.

Mută adresa împreună cu apartenența

În designul cu subinterfață, adresa hostului pentru subrețeaua pusă în bridge aparține pe br_vpn, nu pe portul VLAN subordonat unde ar fi putut sta înainte. Lăsarea ei pe port poate părea că funcționează și apoi se comportă ciudat, pentru că bridge-ul forwardează la nivel 2 în timp ce adresa stă pe un membru. Mută-o ca parte a schimbării de apartenență, nu ca experiment separat.

Mutarea unei adrese poate întrerupe calea de administrare. Stabilește o rută de recuperare independentă, salvează configurația existentă prin propriul manager de rețea al distribuției și evită un script de pornire concurent care va lupta cu el după următoarea actualizare.

Adresarea clienților cere aceeași grijă. Un VPN pus în bridge plasează clienții în subrețeaua extinsă, deci un pool nu trebuie să se suprapună cu alte lease-uri sau alocări statice, iar un aranjament servit de DHCP trebuie să fie cel pe care LAN-ul îl așteaptă cu adevărat. O cale de nivel 2 funcțională nu spune nimic despre adrese duplicate.

Verifică apartenența înainte de a da vina pe rute

Citește starea curentă, nu pe cea intenționată: ip -d link show dev eno1.120 afișează id-ul VLAN și părintele lui, ip link show master br_vpn listează membrii bridge-ului, iar bridge vlan show raportează apartenența pe port și tratamentul de ieșire. În designul cu subinterfață, confirmă că dispozitivul TAP și dispozitivul VLAN sunt membrii. Într-un bridge conștient de VLAN, verifică politica portului însăși, fiindcă un bridge care există nu dovedește ce permite.

Apoi testează un client permis împotriva unui serviciu din acel VLAN, ținând minte că ARP, politica firewall-ului și calea de răspuns sunt chestiuni separate de apartenență. Dacă capturezi pachete, notează că offload-ul hardware poate schimba unde apar tag-urile VLAN într-un trace. Ține și scopul onest: un client TUN rutat nu devine membru VLAN prin nicio schimbare de bridge, iar traficul client-la-client nu înlocuiește atașamentul hostului la VLAN.