साइट 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 लेबल फक्त तिथेच नोंदवा जिथे स्थानिक कार्यांना त्याची गरज असते. मग प्रत्येक कार्यालय आपले स्विचिंग पुन्हा क्रमांकित करू शकते, प्रत्येक बदल टनेलच्या पुनर्रचनेत न बदलता.