एउटा 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 जोडाइलाई प्रतिस्थापन गर्दैन।