शाखा और प्रयोगशाला के बीच लिंक के लिए रूटेड VPN या ब्रिज्ड LAN

किसी शाखा को घरेलू प्रयोगशाला तक पहुँचाने के दो तरीके हैं और अंतर कोई सेटिंग नहीं है। आप अलग-अलग प्रीफ़िक्स के बीच रूट कर सकते हैं, जिससे हर साइट अपना ब्रॉडकास्ट डोमेन रखे, या दोनों LAN को एक में ब्रिज कर सकते हैं, जिससे ब्रॉडकास्ट और डिस्कवरी ट्रैफ़िक ऐसे व्यवहार करें जैसे सब एक ही कमरे में हों। रूटिंग वह डिज़ाइन है जो असली नेटवर्क के संपर्क में टिकता है। ब्रिजिंग वह डिज़ाइन है जो पहला सप्ताह आसान और पहला व्यवधान दिलचस्प बनाता है। नीचे तुलना इस बारे में है कि हर एक क्या देता है और क्या लागत है, और फिर इस बारे में कि रूटेड संस्करण को परखने योग्य कैसे बनाया जाए।

जोड़ने के दो तरीके, एक स्पष्ट समझौता

रूटेड लिंक घरेलू प्रयोगशाला को उसकी अपनी एड्रेसिंग वाला दूरस्थ नेटवर्क मानता है। शाखा प्रयोगशाला का प्रीफ़िक्स माँगती है, टनल उन पैकेटों को ढोता है, और प्रयोगशाला का गेटवे अपने ही सबनेट से जवाब देता है। शाखा की ARP तालिका में कुछ नहीं बदलता, और प्रयोगशाला के DHCP दायरे से कुछ भी शाखा तक नहीं पहुँचता।

ब्रिज्ड लिंक एक ही लेयर 2 डोमेन को दोनों साइटों पर फैलाता है। डिस्कवरी प्रोटोकॉल काम करते हैं, डिवाइस अपने आप दिखने लगते हैं, और हर ब्रॉडकास्ट, हर ARP अनुरोध और हर multicast पैकेट अब टनल पार करने का उम्मीदवार है, यानी बड़ी मात्रा में ट्रैफ़िक जिसे स्थानीय सेगमेंट के लिए बने प्रोटोकॉल ढोते हैं, न कि अलग MTU और बदलते राउंड-ट्रिप समय वाले WAN के लिए।

रूटिंग आपको क्या देती है

पहला फ़ायदा नुकसान का दायरा है। लूप, अनचाहा DHCP सर्वर या ब्रॉडकास्ट की बाढ़ उसी साइट में रहती है जिसने उसे पैदा किया, क्योंकि राउटर ब्रॉडकास्ट आगे नहीं भेजता। दूसरा एड्रेसिंग की स्पष्टता है: शाखा का प्रीफ़िक्स और प्रयोगशाला का प्रीफ़िक्स अलग हैं, इसलिए पैकेट का गंतव्य बताता है कि कौन सी साइट जवाब दे, और फ़ायरवॉल नियम «हर जगह से हर जगह» की जगह «शाखा से प्रयोगशाला सबनेट तक» कह सकता है।

तीसरा यह है कि यह उससे मेल खाता है जो टनल वास्तव में ढोता है। IPsec नीति प्रीफ़िक्स की जोड़ी है, और हर तरफ़ अग्रेषण का रास्ता गेटवे पर अग्रेषण चालू करके सामान्य IP रूटिंग है:

sysctl -w net.ipv4.ip_forward=1
ip route add 10.20.0.0/24 via 192.168.50.1
ip route get 10.20.0.40

जो आप छोड़ते हैं वह ब्रॉडकास्ट के ज़रिए डिस्कवरी है। यह असली नुकसान है और इसे सब कुछ ब्रिज करके बचने की जगह जानबूझकर बदलना चाहिए।

ब्रिजिंग की लागत

ब्रिजिंग को लेयर 2 फ़्रेम टनल से ढोने होते हैं, यानी साधारण नीति-आधारित टनल की जगह IPsec के ऊपर GRE या VXLAN जैसा एनकैप्सुलेशन। जैसे ही यह मौजूद होता है, दोनों साइटें एक ही विफलता डोमेन साझा करती हैं। Spanning tree टनल को लिंक मानता है, ब्रॉडकास्ट ट्रैफ़िक टनल की बैंडविड्थ खाता है, और जो भी डिवाइस कम विलंब वाला सेगमेंट मान लेता है वह ऐसे तरीक़ों से गलत व्यवहार करता है जिन्हें किसी भी सिरे से जोड़ना मुश्किल है।

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

सुरक्षा का तर्क आमतौर पर निर्णायक होता है। ब्रिज उस सेगमेंट को फैलाता है जिस पर लिंक-लोकल प्रोटोकॉल काम करते हैं, इसलिए शाखा का डिवाइस ऐसे प्रयोगशाला उपकरणों से बात कर सकता है जो कभी बाहर से पहुँचने लायक नहीं थे। अगर प्रयोगशाला में उसी सपाट नेटवर्क पर hypervisor, स्टोरेज कंसोल और प्रबंधन इंटरफ़ेस हैं, तो अब वह शाखा के साथ एक ही सेगमेंट है।

ब्रॉडकास्ट के बिना नाम

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

multicast डिस्कवरी कठिन मामला है और इसके लिए सटीकता चाहिए। mDNS जैसे प्रोटोकॉल लिंक-लोकल multicast इस्तेमाल करते हैं जिसे राउटर डिफ़ॉल्ट रूप से आगे नहीं भेजते, इसलिए डिस्कवरी सूची से गायब प्रयोगशाला होस्ट अपने दस्तावेज़ित पते पर अब भी पहुँच योग्य हो सकता है। अगर कोई ख़ास सेवा सचमुच multicast माँगती है, तो पूरे LAN को सामान्य मरम्मत के तौर पर ब्रिज करने की जगह उसी एक प्रोटोकॉल की योजना बनाएँ, किसी रिफ़्लेक्टर या लक्षित अग्रेषण नियम के साथ।

रिफ़्लेक्टर भी मुफ़्त जीत नहीं है। वह वही बातूनी ट्रैफ़िक अंदर लाता है जिससे आप बचना चाहते थे, एक बार में एक सेवा, और उसे ऐसा मालिक चाहिए जो महसूस करे जब कोई डिवाइस पहले से ज़्यादा विज्ञापन देने लगे। उसे हर सेवा के लिए चुनें, और क्यों लिखें। दर्ज करें कि किस सेवा को उसकी ज़रूरत थी और वह क्या विज्ञापन देती है, क्योंकि firmware अपडेट उस सूची को किसी को बताए बिना बदल सकता है।

रूटेड डिज़ाइन को परखने योग्य बनाएँ

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

प्रयोगशाला के सामान्य गेटवे को शाखा प्रीफ़िक्स तक वापसी मार्ग चाहिए, जब तक डिज़ाइन जानबूझकर स्रोत का अनुवाद न करे, और सर्वर के अपने फ़ायरवॉल को अनुमत दूरस्थ श्रेणी स्वीकार करनी चाहिए। इनमें से कुछ भी सफल टनल से कॉन्फ़िगर नहीं होता। strongSwan के अग्रेषण नोट्स उस पैकेट पथ का वर्णन करते हैं जो हर तरफ़ काम करना चाहिए।

फिर मना किया गया गंतव्य भी परखें। शाखा का उपयोगकर्ता जिसे एक एप्लिकेशन चाहिए, उसे hypervisor कंसोल नहीं चाहिए, और यह जानने का एकमात्र तरीका कि नीति असली है, ठीक वही आज़माना है जिसे उसे मना करना चाहिए। प्रीफ़िक्स, रिज़ॉल्वर पर निर्भरता और परीक्षण परिणाम दर्ज करें, और किसी भी साइट में भावी बदलाव स्मृति से दोबारा बनाने की जगह मिनटों में देखा जा सकता है।