क्या दो साइटों को साइट VPN के लिए समान VLAN ID चाहिए?
समान VLAN ID राउटेड साइट VPN को ठीक नहीं कर सकते: टनल IP प्रीफ़िक्स ढोता है, इसलिए पहुँच एड्रेस प्लान और सिलेक्टर तय करते हैं, स्विच टैग नहीं।
दो ऑफ़िसों में समान VLAN नंबर होने से लगता है कि इससे साइट-से-साइट टनल में मदद मिलनी चाहिए, और इससे टनल जो ढोता है उसमें कुछ नहीं बदलता। एक VLAN ID एक इमारत के भीतर Ethernet प्रसारण डोमेन को चिह्नित करता है; टनल गेटवे के बीच IP पैकेट अग्रेषित करता है. दो साइटें पूरी तरह अलग VLAN नंबरिंग इस्तेमाल करके भी एक-दूसरे तक राउट कर सकती हैं, और दो साइटें समान VLAN नंबरिंग इस्तेमाल करके भी एक-दूसरे तक नहीं पहुँच सकतीं। पहुँच तय करने वाला चर एड्रेस प्लान है।
मिथक: दोनों सिरों पर समान VLAN ID
यह विश्वास एक तर्कसंगत जगह से आता है। एक इमारत के भीतर, एक ही VLAN के दो पोर्ट बात कर सकते हैं और अलग VLAN के दो पोर्ट नहीं कर सकते, इसलिए VLAN नंबर वह चीज़ लगता है जो कनेक्टिविटी देती है। राउटेड टनल के पार कोई साझा Ethernet सेगमेंट नहीं होता जिसे टैग वर्णित कर सके, और गेटवे कभी VLAN लेबल का आदान-प्रदान नहीं करते।
टनल को जिस चीज़ की ज़रूरत है वह है बिना ओवरलैप वाले दो एड्रेस स्कोप और उनके बीच ट्रैफ़िक की अनुमति देने वाली नीति। किसी भी ऑफ़िस में VLAN बदलें और टनल काम करती रहती है, क्योंकि टनल कॉन्फ़िगरेशन में किसी चीज़ ने इसका संदर्भ नहीं दिया था। यही वह परीक्षण है जो विवाद तय करता है: VLAN का फिर से नंबरिंग करें, एड्रेस अछूते छोड़ें और देखें कि टनल टिकती है या नहीं।
उलटा परीक्षण भी उतना ही जानकारीपूर्ण है। दोनों ऑफ़िसों को एक ही सबनेट दें और समान VLAN नंबर कितने भी हों, वे किसी एड्रेस को असंदिग्ध नहीं बनाएँगे।
टनल वास्तव में क्या ढोती है
IPsec एड्रेस, प्रोटोकॉल और पोर्ट में व्यक्त नीति के अनुसार IP पैकेट की रक्षा करता है। IPsec आर्किटेक्चर IP परत पर उन सिलेक्टरों का वर्णन करता है, जो स्विच टैग द्वारा वर्णित किसी भी चीज़ से कई परतें ऊपर है। जब कोई पैकेट टनल में प्रवेश करता है तो वह VLAN पहले ही छोड़ चुका होता है; टैग स्थानीय स्विच ने खपा दिया है।
नीति-आधारित और रूट-आधारित डिज़ाइन टनल चुनने के तरीके में भिन्न हैं, इसमें नहीं कि वे क्या ढो सकते हैं. नीति-आधारित पीयर ट्रैफ़िक सिलेक्टर मिलाता है और मेल खाते पैकेट टनल में भेजता है। रूट-आधारित पीयर टनल इंटरफ़ेस पर ट्रैफ़िक राउट करता है और निर्णय राउटिंग तालिका पर छोड़ता है। दोनों अभी भी सुरक्षा-क्षेत्र पर बातचीत करते हैं, इसलिए टनल की ओर इशारा करने वाला रूट उस चीज़ का विस्तार नहीं करता जिसे पीयर सुरक्षित करने पर सहमत हुए थे।
यह अंतर एक सामान्य आधी-विफलता की व्याख्या करता है: रूट मौजूद है, पैकेट टनल में प्रवेश करते हैं, और दूर का पक्ष उन्हें गिरा देता है क्योंकि बातचीत किए गए सिलेक्टरों में वह प्रीफ़िक्स कभी शामिल नहीं था। स्थापित नीतियों को पढ़ने से पता चलता है कि कौन-सा क्षेत्र वास्तव में लागू हुआ।
ip xfrm policy
ip route show
swanctl --list-sasवह ओवरलैप जो वास्तव में तोड़ता है
अलग सबनेट वाले दो ऑफ़िस टनल से साफ़-सुथरे राउट होते हैं, और उनके VLAN नंबर अप्रासंगिक हैं। एक ही सबनेट वाले दो ऑफ़िस नहीं, क्योंकि किसी दिए गए एड्रेस के अनुरोध के दो संभावित अर्थ होते हैं और राउटिंग तालिका केवल एक चुन सकती है। एक साइट का फिर से नंबरिंग करना साफ़ समाधान है, और DNS तथा फ़ायरवॉल बदलावों को गिनने के बाद यह आमतौर पर विकल्पों से सस्ता पड़ता है।
| Office | Local VLAN | Subnet | Result |
|---|---|---|---|
| A | 40 | 10.31.0.0/24 | Routes normally |
| B | 55 | 10.62.0.0/24 | Routes normally |
| B after renumber | 40 | 10.31.0.0/24 | Ambiguous, tunnel cannot help |
जब फिर से नंबरिंग असंभव हो, तो एक सुविचारित अनुवाद डिज़ाइन हर पक्ष को अलग एड्रेस दृश्य दे सकता है। इसका अर्थ है एक-से-एक मैपिंग, मेल खाते सिलेक्टर, अनूदित दृश्य को दर्शाने वाली DNS प्रविष्टियाँ और ऐसा लौटने वाला राउटिंग जो पुनर्लेखन को झेलता है। यह वास्तविक परिचालन लागत वाला समर्थित डिज़ाइन है, और VLAN ID बदलने से जो होता है वह यह नहीं है।
दोनों सिरों पर समान VLAN नंबर कभी-कभी साझा टेम्पलेट का संयोग होते हैं, और उस संयोग को काम करती टनल का कारण मानना बाद में कुछ टूटने पर गलत बदलाव की ओर ले जाता है।
हर परत के लिए एक काम, लिखित रूप में
स्थानीय स्विच तय करता है कि कौन-से पोर्ट एक प्रसारण डोमेन साझा करते हैं, और उसकी VLAN नंबरिंग स्थानीय लेखांकन है जिसे किसी अन्य साइट को जानने की ज़रूरत नहीं। गेटवे पीयर को प्रमाणित करता है और बातचीत किए गए सुरक्षा-क्षेत्र को लागू करता है। राउटिंग तालिका तय करती है कि डिक्रिप्ट किया गया पैकेट आगे कहाँ जाएगा, और एक्सेस नीति तय करती है कि उस पैकेट को बिलकुल अनुमति दी जानी चाहिए थी या नहीं।
इन कामों को अलग रखना ही बदलावों को सुरक्षित बनाता है। एक ऑफ़िस में VLAN फिर से नंबरिंग स्थानीय स्विच, DHCP स्कोप और संभवतः फ़ायरवॉल ज़ोन को छूती है, और टनल को नहीं छूती। प्रीफ़िक्स बदलाव टनल सिलेक्टरों, दोनों ओर के रूट और एक्सेस नीति को छूता है, और स्विच टैग को नहीं छूता।
लौटने वाले रूट, निजी DNS और एप्लिकेशन पहचान की आवश्यकताएँ फिर अलग काम हैं, और उनमें से कोई भी दूसरी साइट से VLAN नंबर कॉपी करके नहीं आता। जो डिज़ाइन दस्तावेज़ पहुँच योग्य प्रीफ़िक्स और अनुमत सेवाओं की सूची देता है वह स्विच बदलाव के बाद भी टिकता है; जो VLAN नंबरों की सूची देता है वह नहीं।
यह मानने से पहले कि कोई टैग टनल तक पहुँचता है, ब्रिज उपकरणों से स्थानीय तस्वीर की पुष्टि करें।
bridge vlan show
ip -br addr
ip route get 10.62.0.20जब layer-2 विस्तार ही वास्तविक आवश्यकता हो
कुछ डिज़ाइनों को साइटों के बीच वास्तव में Ethernet व्यवहार चाहिए: प्रसारण खोज पर निर्भर पुराना एप्लिकेशन, ऐसा माइग्रेशन जिसमें मशीन खिसकते समय एड्रेस बनाए रखना हो, या ऐसा प्रोटोकॉल जो layer-2 मान्यताएँ समेटे हो। ऐसे मामलों में फ़्रेम ढोने वाला ओवरले या ब्रिज्ड सेवा चाहिए, और तब VLAN सदस्यता, लूप रोकथाम तथा विफलता प्रबंधन शुरू-से-अंत तक के मामले बन जाते हैं।
यह बहुत बड़ा विफलता डोमेन है, और इसे फ़ाइल साझा करने को चलाने की कोशिश का आकस्मिक परिणाम नहीं, सुविचारित विकल्प होना चाहिए। सामान्य फ़ाइल सर्वर, डेटाबेस या वेब एप्लिकेशन को अधिकृत IP पथ चाहिए, और उसके नीचे खिंचे प्रसारण डोमेन के बिना वह अधिक प्रसन्न रहेगा।
VPN अनुबंध को पहुँच योग्य प्रीफ़िक्स और अनुमत सेवाओं के रूप में लिखें, और VLAN लेबल केवल वहीं दर्ज करें जहाँ स्थानीय संचालन को इसकी ज़रूरत हो। तब हर ऑफ़िस अपनी स्विचिंग का फिर से नंबरिंग कर सकता है, बिना हर बदलाव को टनल का पुनर्डिज़ाइन बनाए।