TAP tiltas vienam VLAN: prijunkite subsąsają

TAP klientas, kuris pasiekė LAN prieš VLAN ir po to nustojo veikti, paprastai turi tiltą, kuriame vis dar yra netinkama sąsaja. Kadrų persiuntimas neprideda VLAN žymos, todėl į fizinį uplinką išsiųstas kliento kadras be žymos atvyksta be žymos į trunk prievadą ir yra arba atmetamas, arba patenka į vietinį VLAN. Tai, kad subsąsaja kažkur yra hoste, nieko nekeičia tilto narių sąraše. Tai mitas, kurį reikia sunaikinti pirmiausia: žymą uždeda sąsaja, kuriai ji priklauso, o ne hostas, kuris tiesiog ją turi.

Vienas VLAN išplėtimas reiškia vieną 2 sluoksnio domeną, ir tiltas turi prisijungti prie to domeno, o ne prie trunko, kuris juos visus neša.

Žyma nepasirodo, nes prijungėte trunką prie tilto

Imkite Linux uplinką eno1 su VLAN 120 ir prijunkite prie valdomo komutatoriaus. Vienam VLAN tinkanti konstrukcija yra tap_vpn, sujungtas tiltu su br_vpn, o br_vpn turi eno1.120, o ne eno1. VLAN subsąsaja uždeda žymą išėjime ir ją nuima įėjime, todėl tiltas mato tik be žymos kadrus tam vienam VLAN. Vietoje to įdėkite fizinę sąsają į tiltą, ir tie patys kadrai išeis be žymos į trunk prievadą, o tai nebuvo suplanuota.

Trunko tiltinimas išjungus VLAN filtrą nėra trumpesnis kelias į tą patį rezultatą. Tai perduoda tiltui kiekvieną tame laide esantį VLAN, įskaitant tuos, kurių klientai neturėtų matyti.

Dvi teisėtos konstrukcijos, vienas žymos savininkas

VLAN žinantis tiltas yra kita galiojanti tvarka: trunkas patenka į tilto prievadą, o narystė pagal prievadą, PVID ir žymėti išėjimo nustatymai nusprendžia, kurie VLAN praeis. Ten žymėjimą valdo tiltas, o VLAN subsąsajos įdėjimas po juo įrengtų antrą savininką vienai užduočiai. Abi konstrukcijos veikia; abiejų fragmentai ne. Nuspręskite, kuris objektas deda žymą, prieš keisdami bet kokį narių sąrašą.

Komutatoriaus prievadas turi sutikti su bet kuria pasirinkta konstrukcija. Access prievadas, nešantis VLAN be žymos, dera su fizine sąsaja kaip prisijungimu, o trunk prievadas dera su žymėta subsąsaja. Subsąsajos pridėjimas prie netinkamo access prievado nieko netaiso.

Perkelkite adresą kartu su naryste

Subsąsajos konstrukcijoje hosto adresas tiltiniam potinkiui priklauso br_vpn, o ne pavergtam VLAN prievadui, kuriame jis galėjo būti anksčiau. Palikus jį prievade, gali atrodyti, kad veikia, o paskui elgtis keistai, nes tiltas persiunčia 2 sluoksnyje, o adresas yra ant nario. Perkelkite jį kaip narystės pakeitimo dalį, o ne kaip atskirą eksperimentą.

Adreso perkėlimas gali nutraukti administravimo kelią. Įrenkite nepriklausomą atkūrimo kelią, išsaugokite esamą konfigūraciją per pačios distribucijos tinklo tvarkyklę ir venkite konkuruojančio paleidimo scenarijaus, kuris kovos su ja po kito atnaujinimo.

Klientų adresavimas reikalauja tokio paties rūpestingumo. Tiltinis VPN patalpina klientus išplėstame potinkyje, todėl adresų bazė neturi persidengti su kitomis nuomomis ar statiniais priskyrimais, o DHCP aptarnaujama tvarka turi būti ta, kurios LAN tikrai laukia. Veikiantis 2 sluoksnio kelias nieko nesako apie pasikartojančius adresus.

Patikrinkite narystę prieš kaltindami maršrutus

Skaitykite dabartinę būseną, o ne numatytąją: ip -d link show dev eno1.120 išspausdina VLAN id ir jo tėvą, ip link show master br_vpn išvardija tilto narius, o bridge vlan show praneša narystę pagal prievadą ir išėjimo apdorojimą. Subsąsajos konstrukcijoje patvirtinkite, kad TAP įrenginys ir VLAN įrenginys yra nariai. VLAN žinančiame tilte patikrinkite pačią prievado politiką, nes egzistuojantis tiltas neįrodo, ką jis leidžia.

Tada išbandykite vieną leistą klientą prieš paslaugą tame VLAN, atsimindami, kad ARP, ugniasienės politika ir atsakymo kelias yra atskiri klausimai nuo narystės. Jei fiksuojate paketus, atkreipkite dėmesį, kad techninės įrangos offload gali pakeisti, kur VLAN žymos pasirodo trace. Taip pat laikykite apimtį sąžiningą: maršrutizuotas TUN klientas netampa VLAN nariu dėl jokio tilto pakeitimo, o klientų tarpusavio srautas nepakeičia hosto prisijungimo prie VLAN.