एक VLAN के लिए TAP ब्रिज: सबइंटरफ़ेस जोड़ें

जो TAP क्लाइंट VLAN से पहले LAN तक पहुँचता था और बाद में रुक गया, उसके पास आम तौर पर ऐसा ब्रिज होता है जिसमें अभी भी गलत इंटरफ़ेस है। फ़्रेम फ़ॉरवर्डिंग VLAN टैग नहीं जोड़ती, इसलिए भौतिक अपलिंक पर भेजा गया बिना टैग वाला क्लाइंट फ़्रेम ट्रंक पोर्ट पर बिना टैग पहुँचता है और या तो छोड़ दिया जाता है या मूल VLAN में गिर जाता है। होस्ट पर कहीं सबइंटरफ़ेस का होना ब्रिज की सदस्य सूची में कुछ नहीं बदलता। पहले इसी मिथक को मारना है: टैग वह इंटरफ़ेस लगाता है जिसके पास वह है, न कि होस्ट केवल इसलिए कि उसके पास एक है।

एक VLAN विस्तार का अर्थ एक layer-2 डोमेन है, और ब्रिज को सबको ले जाने वाले ट्रंक के बजाय उसी डोमेन से जुड़ना है।

टैग इसलिए नहीं दिखता कि आपने ट्रंक ब्रिज किया

VLAN 120 को प्रबंधित स्विच तक ले जाने वाला Linux अपलिंक eno1 लें। एक ही VLAN के लिए काम करने वाला डिज़ाइन tap_vpn को br_vpn से ब्रिज करना है, जिसमें br_vpn में eno1 के बजाय eno1.120 होता है। VLAN सबइंटरफ़ेस बाहर जाते समय टैग लगाता है और अंदर आते समय हटा देता है, इसलिए ब्रिज उस एक VLAN के लिए केवल बिना टैग वाले फ़्रेम देखता है। इसके बजाय भौतिक इंटरफ़ेस को ब्रिज में रखें, तो वही फ़्रेम ट्रंक पोर्ट पर बिना टैग निकलेंगे, जो आपने योजना बनाई थी वह नहीं है।

VLAN फ़िल्टरिंग बंद रखते हुए ट्रंक ब्रिज करना उसी परिणाम का शॉर्टकट नहीं है। यह उस तार के हर VLAN को ब्रिज को दे देता है, उन सहित जिन्हें क्लाइंट को नहीं देखना चाहिए।

दो वैध डिज़ाइन, टैग का एक मालिक

VLAN-जागरूक ब्रिज दूसरी वैध व्यवस्था है: ट्रंक ब्रिज पोर्ट में प्रवेश करता है, और प्रति-पोर्ट सदस्यता, PVID तथा टैग वाले आउटग्रेस सेटिंग्स तय करते हैं कि कौन से VLAN पार होंगे। वहाँ टैगिंग का मालिक ब्रिज है, और उसके नीचे VLAN सबइंटरफ़ेस जोड़ना एक ही काम के लिए दूसरा मालिक बना देगा। दोनों डिज़ाइन काम करते हैं; दोनों के टुकड़े नहीं। कोई भी सदस्य सूची संपादित करने से पहले तय करें कि कौन सी वस्तु टैग लगाती है।

स्विच पोर्ट को आपके चुने डिज़ाइन से मेल खाना चाहिए। VLAN को बिना टैग ले जाने वाला एक्सेस पोर्ट भौतिक इंटरफ़ेस के साथ जुड़ाव के रूप में मेल खाता है, जबकि ट्रंक पोर्ट टैग वाले सबइंटरफ़ेस से मेल खाता है। अनुपयुक्त एक्सेस पोर्ट में सबइंटरफ़ेस जोड़ने से कुछ ठीक नहीं होता।

पता सदस्यता के साथ ले जाएँ

सबइंटरफ़ेस डिज़ाइन में, ब्रिज किए गए सबनेट के लिए होस्ट का पता br_vpn पर होना चाहिए, न कि उस गुलाम VLAN पोर्ट पर जहाँ वह पहले रह सकता था। उसे पोर्ट पर छोड़ना काम करता दिख सकता है और फिर अजीब व्यवहार कर सकता है, क्योंकि ब्रिज layer 2 पर फ़ॉरवर्ड करता है जबकि पता एक सदस्य पर बैठा है। इसे अलग प्रयोग के बजाय सदस्यता परिवर्तन के हिस्से के रूप में ले जाएँ।

पता ले जाने से प्रशासन पथ कट सकता है। एक स्वतंत्र पुनर्प्राप्ति मार्ग स्थापित करें, वितरण के अपने नेटवर्क प्रबंधक के माध्यम से मौजूदा कॉन्फ़िगरेशन सहेजें, और अगले उन्नयन के बाद उससे लड़ने वाली प्रतिस्पर्धी स्टार्टअप स्क्रिप्ट से बचें।

क्लाइंट पतों को भी वही सावधानी चाहिए। ब्रिज किया गया VPN क्लाइंट को विस्तारित सबनेट में रखता है, इसलिए पूल अन्य लीज़ या स्थिर आवंटनों से ओवरलैप नहीं होना चाहिए, और DHCP द्वारा दी जाने वाली व्यवस्था वही होनी चाहिए जिसकी LAN वास्तव में अपेक्षा करता है। काम करता layer-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 जुड़ाव का विकल्प नहीं है।