साइट 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 लेबललाई स्थानीय कामकाजलाई आवश्यक पर्ने ठाउँमा मात्र अभिलेख गर्नुहोस्। तब प्रत्येक कार्यालयले प्रत्येक परिवर्तनलाई टनेल पुनःडिजाइन नबनाई आफ्नै स्विचिङ पुनः नम्बर गर्न सक्छ।