एका VLAN साठी TAP ब्रिज: उप-इंटरफेस जोडा

VLAN आधी LAN पर्यंत पोहोचलेला आणि नंतर थांबलेला TAP क्लायंट सहसा अजूनही चुकीचा इंटरफेस असलेला ब्रिज ठेवतो। फ्रेम फॉरवर्डिंग VLAN टॅग जोडत नाही, म्हणून फिजिकल अपलिंकवर पाठवलेले टॅग नसलेले क्लायंट फ्रेम ट्रंक पोर्टवर टॅग न करता येते आणि एकतर टाकले जाते किंवा नेटिव्ह VLAN मध्ये जाते। उप-इंटरफेस होस्टवर कुठेतरी असणे ब्रिजच्या सदस्य यादीत काहीही बदलत नाही। प्रथम मारायची दंतकथा हीच आहे: टॅग तो असलेला इंटरफेस लावतो, होस्टकडे तो फक्त असल्यामुळे नाही।

एक VLAN विस्तार म्हणजे एक 2-स्तरीय डोमेन, आणि ब्रिजने सर्वांना वाहणाऱ्या ट्रंकमध्ये नाही, त्या डोमेनमध्ये सामील व्हावे।

टॅग दिसत नाही कारण तुम्ही ट्रंक ब्रिज केला

VLAN 120 वाहणारा Linux अपलिंक eno1 व्यवस्थापित स्विचकडे घ्या। एका VLAN साठी चालणारी रचना म्हणजे tap_vpn br_vpn ला ब्रिज केलेला, br_vpn मध्ये eno1 नाही तर eno1.120 असतो। VLAN उप-इंटरफेस बाहेर जाताना टॅग लावतो आणि आत येताना काढतो, म्हणून ब्रिज त्या एका VLAN साठी फक्त टॅग नसलेली फ्रेम्स पाहतो। त्याऐवजी फिजिकल इंटरफेस ब्रिजमध्ये ठेवा, तीच फ्रेम्स ट्रंक पोर्टवर टॅग न करता बाहेर पडतात, जे तुम्ही नियोजित केले नव्हते।

VLAN फिल्टरिंग बंद करून ट्रंक ब्रिज करणे हा त्याच निकालाकडे जाणारा सोपा मार्ग नाही। तो त्या तारेवरील प्रत्येक VLAN ब्रिजला देतो, जे क्लायंटने पाहू नयेत तेही।

दोन वैध रचना, एक टॅग मालक

VLAN-जाणणारा ब्रिज ही दुसरी वैध व्यवस्था आहे: ट्रंक ब्रिज पोर्टमध्ये जातो, आणि पोर्टनुसार सदस्यत्व, PVID आणि टॅग केलेल्या आउटपुट सेटिंग्ज कोणते VLAN जातील ते ठरवतात। तिथे टॅगिंग ब्रिजचे असते, आणि त्याखाली VLAN उप-इंटरफेस जोडल्यास एका कामासाठी दुसरा मालक बसवला जाईल। दोन्ही रचना चालतात; दोहोंचे तुकडे चालत नाहीत। कोणतीही सदस्य यादी संपादित करण्यापूर्वी कोणती वस्तू टॅग लावते ते ठरवा।

स्विच पोर्टने तुम्ही निवडलेल्या कोणत्याही रचनेशी सहमत असणे आवश्यक आहे। VLAN टॅग न करता वाहणारा access पोर्ट फिजिकल इंटरफेसशी जोडणी म्हणून जुळतो, तर ट्रंक पोर्ट टॅग केलेल्या उप-इंटरफेसशी जुळतो। न जुळणाऱ्या access पोर्टवर उप-इंटरफेस जोडल्याने काहीही दुरुस्त होत नाही।

पत्ता सदस्यत्वासोबत हलवा

उप-इंटरफेस रचनेत, ब्रिज केलेल्या सबनेटसाठी होस्टचा पत्ता br_vpn वर असतो, पूर्वी असू शकलेल्या गुलाम VLAN पोर्टवर नाही। तो पोर्टवर ठेवल्यास चालत असल्यासारखे वाटू शकते आणि नंतर विचित्र वागू शकते, कारण ब्रिज 2-स्तरावर फॉरवर्ड करतो तर पत्ता सदस्यावर बसतो। तो स्वतंत्र प्रयोग म्हणून नाही, सदस्यत्व बदलाचा भाग म्हणून हलवा।

पत्ता हलवल्याने प्रशासन मार्ग तुटू शकतो। स्वतंत्र पुनर्प्राप्ती मार्ग स्थापित करा, विद्यमान कॉन्फिगरेशन वितरणाच्या स्वतःच्या नेटवर्क मॅनेजरद्वारे जतन करा, आणि पुढील अपग्रेडनंतर त्याच्याशी भिडणारी स्पर्धक स्टार्टअप स्क्रिप्ट टाळा।

क्लायंट पत्ता देण्यासही तितकीच काळजी हवी। ब्रिज केलेले VPN क्लायंटना विस्तारित सबनेटमध्ये ठेवते, म्हणून पूल इतर लीज किंवा स्थिर नियुक्त्यांशी एकत्र येऊ नये, आणि DHCP द्वारे दिलेली व्यवस्था LAN खरोखर अपेक्षित असलेलीच असावी। चालणारा 2-स्तरीय मार्ग डुप्लिकेट पत्त्यांविषयी काहीही सांगत नाही।

मार्गांना दोष देण्यापूर्वी सदस्यत्व तपासा

इच्छित स्थिती नाही, सध्याची स्थिती वाचा: ip -d link show dev eno1.120 VLAN id आणि त्याचा पालक छापतो, ip link show master br_vpn ब्रिज सदस्यांची यादी करतो, आणि bridge vlan show पोर्टनुसार सदस्यत्व आणि आउटपुट हाताळणी नोंदवतो। उप-इंटरफेस रचनेत, TAP उपकरण आणि VLAN उपकरण सदस्य आहेत याची खात्री करा। VLAN-जाणणाऱ्या ब्रिजमध्ये, पोर्ट धोरणच तपासा, कारण ब्रिज अस्तित्वात असणे तो काय परवानगी देतो हे सिद्ध करत नाही।

नंतर परवानगी असलेल्या एका क्लायंटची त्या VLAN मधील सेवेशी चाचणी करा, ARP, फायरवॉल धोरण आणि उत्तर मार्ग हे सदस्यत्वापेक्षा वेगळे मुद्दे आहेत हे लक्षात ठेवा। तुम्ही पॅकेट पकडत असल्यास, हार्डवेअर ऑफलोडमुळे ट्रेसमध्ये VLAN टॅग कुठे दिसतात ते बदलू शकते याची नोंद घ्या। व्याप्तीही प्रामाणिक ठेवा: राउटेड TUN क्लायंट कोणत्याही ब्रिज बदलामुळे VLAN सदस्य होत नाही, आणि क्लायंट-ते-क्लायंट रहदारी होस्ट-ते-VLAN जोडणीची जागा घेत नाही।