TAP tilts vienam VLAN: pievienojiet apakšsaskarni

TAP klients, kas sasniedza LAN pirms VLAN un pēc tam apstājās, parasti joprojām satur tiltu ar nepareizo saskarni. Kadru pārsūtīšana nepievieno VLAN birku, tāpēc uz fizisko uplinku nosūtīts klienta kadrs bez birkas ierodas bez birkas trunk portā un tiek vai nu izmests, vai arī nokļūst vietējā VLAN. Tas, ka apakšsaskarne kaut kur atrodas uz resursdatora, neko nemaina tilta dalībnieku sarakstā. Tas ir mīts, kas jāiznīcina vispirms: birku uzliek saskarne, kurai tā pieder, nevis resursdators, kuram tā vienkārši ir.

Viens VLAN paplašinājums nozīmē vienu 2 līmeņa domēnu, un tiltam jāpievienojas šim domēnam, nevis trunkam, kas pārnēsā tos visus.

Birka neparādās tāpēc, ka trunk tika savienots ar tiltu

Ņemiet Linux uplink eno1 ar VLAN 120 un pievienojiet pārvaldītam komutatoram. Konstrukcija, kas darbojas vienam VLAN, ir tap_vpn, savienots tiltā ar br_vpn, kur br_vpn satur eno1.120, nevis eno1. VLAN apakšsaskarne uzliek birku izejā un noņem to ieejā, tāpēc tilts redz tikai kadrus bez birkas šim vienam VLAN. Tā vietā ievietojiet fizisko saskarni tiltā, un tie paši kadri izies bez birkas trunk portā, kas nav tas, ko jūs plānojāt.

Trunka tiltināšana ar izslēgtu VLAN filtrēšanu nav īsceļš uz to pašu rezultātu. Tā nodod tiltam katru VLAN uz šī vada, tostarp tos, kurus klientiem nav jāredz.

Divi likumīgi risinājumi, viens birkas īpašnieks

VLAN apzinīgs tilts ir otra derīgā kārtība: trunks nonāk tilta portā, un dalība pa portiem, PVID un birkotas izejas iestatījumi nosaka, kuri VLAN iziet. Tur birkas piešķiršanu pārvalda tilts, un VLAN apakšsaskarnes pievienošana zem tā uzstādītu otru īpašnieku vienam darbam. Abi risinājumi darbojas; abu fragmenti nedarbojas. Izlemiet, kurš objekts uzliek birku, pirms maināt jebkuru dalībnieku sarakstu.

Komutatora portam jāsaskan ar jebkuru izvēlēto risinājumu. Access ports, kas pārnēsā VLAN bez birkas, atbilst fiziskajai saskarnei kā pieslēgumam, savukārt trunk ports atbilst birkotai apakšsaskarnei. Apakšsaskarnes pievienošana neatbilstošam access portam neko nelabo.

Pārvietojiet adresi kopā ar dalību

Apakšsaskarnes risinājumā resursdatora adrese tiltotajam apakštīklam pieder br_vpn, nevis pakļautajam VLAN portam, kur tā varēja būt agrāk. Atstājot to portā, tas var šķist darbojamies un pēc tam uzvesties dīvaini, jo tilts pārsūta 2 līmenī, kamēr adrese atrodas uz dalībnieka. Pārvietojiet to kā dalības maiņas daļu, nevis kā atsevišķu eksperimentu.

Adreses pārvietošana var pārtraukt administrēšanas ceļu. Izveidojiet neatkarīgu atkopšanas ceļu, saglabājiet esošo konfigurāciju ar pašas distribūcijas tīkla pārvaldnieku un izvairieties no konkurējoša starta skripta, kas pēc nākamā atjauninājuma cīnīsies ar to.

Klientu adresācijai nepieciešama tāda pati rūpība. Tiltotais VPN ievieto klientus paplašinātajā apakštīklā, tāpēc adrešu pūlam nevajadzētu pārklāties ar citām nomām vai statiskām piešķiršanām, un DHCP apkalpotajam risinājumam jābūt tam, ko LAN patiešām gaida. Darbojošs 2 līmeņa ceļš neko nepasaka par dublētām adresēm.

Pārbaudiet dalību, pirms vainojat maršrutus

Lasiet pašreizējo stāvokli, nevis iecerēto: ip -d link show dev eno1.120 izdrukā VLAN id un tā vecāku, ip link show master br_vpn uzskaita tilta dalībniekus, un bridge vlan show ziņo dalību pa portiem un izejas apstrādi. Apakšsaskarnes risinājumā pārliecinieties, ka TAP ierīce un VLAN ierīce ir dalībnieki. VLAN apzinīgā tiltā pārbaudiet pašu porta politiku, jo esošs tilts nepierāda, ko tas pieļauj.

Pēc tam pārbaudiet vienu atļautu klientu pret pakalpojumu šajā VLAN, atceroties, ka ARP, ugunsmūra politika un atbildes ceļš ir atsevišķi jautājumi no dalības. Ja uzņemat paketes, ņemiet vērā, ka aparatūras offload var mainīt, kur VLAN birkas parādās trace. Turiet arī tvērumu godīgu: maršrutēts TUN klients nekļūst par VLAN dalībnieku ar jebkādu tilta maiņu, un klientu savstarpējā plūsma neaizstāj resursdatora pievienojumu VLAN.