होम-लैब स्प्लिट टनल: जो चाहिए उसे रूट करें, सब कुछ नहीं
फुल टनल एक ट्यूटोरियल की आदत है, लैब की ज़रूरत नहीं। जिन सबनेट, नामों और प्रबंधन पथों की आपको सचमुच ज़रूरत है उन्हें सूचीबद्ध करें, फिर सिर्फ़ उन्हीं को रूट करें।
यह सलाह कि होम-लैब को फुल टनल चाहिए, आमतौर पर ऐसे ट्यूटोरियल से आती है जिसमें वह था, किसी ज़रूरत से नहीं। स्प्लिट टनलिंग किसी सही VPN का समझौता-वाला संस्करण नहीं है; यह वह संस्करण है जिसकी रूट तालिका आप समझा सकते हैं। पाँच सेवाओं और एक प्रबंधन इंटरफ़ेस वाली लैब को यह नहीं चाहिए कि घर से निकलने वाला हर पैकेट टनल से गुज़रे। उसे चाहिए एक सूची और उस सूची की हर वस्तु के लिए एक रूट।
मिथक: स्प्लिट टनलिंग एक समझौता है
मिथक इसलिए टिका है कि फुल टनल एक बार सेट करना आसान और बाद में डिबग करना मुश्किल है। यह सौदा सार्वजनिक Wi-Fi पर लैपटॉप के लिए उचित है और तहखाने में रखे रैक के लिए ग़लत।
यह एक दूसरी धारणा भी छिपाता है, कि लैब का एड्रेसिंग उस नेटवर्क से कुछ भी साझा नहीं करता जिससे आप जुड़ते हैं।
रूट से पहले संसाधनों की सूची बनाएँ
हर लैब सबनेट, वहाँ रहने वाली सेवा, जिस नाम से आप उसे हल करते हैं और किसे उस तक पहुँचने की अनुमति है, लिखें; आपके फ़ॉरवर्डिंग नोट्स गेटवे के लिए वह वापसी पथ बताते हैं जिसके आधार पर आप योजना बनाते हैं। कंटेनर रेंज और वे LAN रेंज जोड़ें जिन्हें रिमोट क्लाइंट पहले से इस्तेमाल कर सकता है, क्योंकि ओवरलैप वह विफलता है जिसे यह सूची रोकती है। हर निजी पते को कवर करने वाला रूट देर-सबेर किसी घरेलू नेटवर्क से टकराएगा। सूची परीक्षण योजना भी है, इसलिए इसे कॉन्फ़िगरेशन के बाद नहीं, पहले करना उचित है।
हर संसाधन को एक पथ दें: टनल से, सीधे, या अस्वीकृत। बिना पथ वाला संसाधन ही बाद में उलझन भरा सहायता प्रश्न पैदा करता है।
पाँच पंक्तियाँ और निर्णयों का एक स्तंभ ऐसी रूट तालिका से बेहतर है जिसे कोई पढ़ नहीं सकता।
गेटवे को वापसी पथ चाहिए
गेटवे पर फ़ॉरवर्डिंग आधी बात है। लैब को क्लाइंट पूल तक वापसी का रूट चाहिए, या ऐसी समर्थित अनुवाद व्यवस्था जो वापसी को संभव बनाए। अगर उत्तर क्लाइंट को नहीं ढूँढ पाते, तो टनल जुड़ा दिखता है और हर अनुरोध समय-समाप्त होता है; यह रूटिंग का लक्षण है, VPN की विफलता नहीं। वापसी पथ को डिज़ाइन का हिस्सा मानकर जाँचें, समस्या-निवारण का कदम नहीं।
लैब के अपने एड्रेसिंग से ओवरलैप करता क्लाइंट पूल इस समस्या का दूसरा आधा है, और यह ठीक उसी तरह विफल होता है।
जब दोनों रेंज टकराएँ तो लक्षण नहीं, योजना सुधारें।
प्रबंधन और इंटरनेट की भूमिकाएँ अलग हैं
तय करें कि टनल सिर्फ़ लैब ट्रैफ़िक के लिए है या वह इंटरनेट निकास भी बनेगा। सिर्फ़ इसलिए डिफ़ॉल्ट रूट न जोड़ें कि किसी ट्यूटोरियल ने जोड़ा था, क्योंकि यह निर्णय बदलता है कि हर DNS क्वेरी और हर अपडेट जाँच कहाँ जाएगी। VPN एंडपॉइंट तक बाहरी पथ बनाए रखें, वरना टनल अपना बाहरी कनेक्शन खुद ढोने की कोशिश करेगा। प्रबंधन पहुँच संकरी और स्वीकृत रिकवरी विधि से सुलभ रखें।
लैब नामों के लिए निजी DNS चुना जा सकता है, बिना यह माने कि हर सार्वजनिक क्वेरी को वही रिज़ॉल्वर चाहिए। यह रिज़ॉल्वर का निर्णय है, रूट का निर्णय नहीं।
इन्हें अलग रखना ही बाद में विफलता के तरीकों को अलग पहचानने योग्य बनाता है।
बाहर से परखें, LAN से नहीं
उसी LAN से परीक्षण के बजाय बाहरी अधिकृत कनेक्शन इस्तेमाल करें, क्योंकि उसी LAN से किया परीक्षण छूटे हुए वापसी रूट को पूरी तरह छिपा सकता है। एक लैब पता, उसका निजी होस्टनाम, इच्छित सीधा गंतव्य और ज़रूरी विफलता व्यवहार सत्यापित करें। विफलता का मामला सफलता के मामले जितना ही महत्वपूर्ण है: जिस संसाधन तक पहुँचना नहीं चाहिए, वहाँ सचमुच नहीं पहुँचना चाहिए। डिज़ाइन पूरा कहने से पहले चारों नतीजे दर्ज करें।
फिर रूट और DNS कॉन्फ़िगरेशन सूची के पास सहेजें, मालिक का नाम के साथ। जब लैब को एक और सबनेट मिले, दोनों अपडेट करें और फिर परखें।
मौजूदा घरेलू नेटवर्क से ओवरलैप करता अस्पष्ट रूट उस कदम को छोड़ने का डिफ़ॉल्ट नतीजा है।
तैयार डिज़ाइन छोटा, प्रलेखित और उबाऊ है, और लैब अपने नेटवर्क से ठीक यही चाहती है। दिलचस्प संस्करण वह है जो आपके घर से दूर रहते हुए टूटता है।