जब रिमोट-एक्सेस क्लाइंट को शाखा गेटवे की भूमिका निभानी हो

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

प्रोटोकॉल लेबल आपको क्या नहीं बताता

OpenVPN साइट-से-साइट डिज़ाइन का दस्तावेज़ीकरण करता है जिसमें एक कनेक्टर पूरा सबनेट फ़ॉरवर्ड करता है, और Access Server उसे गेटवे भूमिका और स्पष्ट राउटिंग के साथ लागू करता है। SSL VPN के रूप में बेचा जाने वाला दूसरा उत्पाद केवल रिमोट-उपयोगकर्ता फ़ंक्शन दे सकता है, क्लाइंट के पीछे के नेटवर्क की घोषणा करने का कोई समर्थित तरीका बिना। संस्करण भी मायने रखता है, क्योंकि एक संस्करण की सुविधा दूसरे के बारे में वादा नहीं है। जो कार्यान्वयन आप वास्तव में चलाते हैं उसे पढ़ें, और दूसरे उत्पाद के लिए लिखी रेसिपी को डिज़ाइन नहीं, संकेत मानें।

पहले तय करने वाला सवाल यह है कि क्या VPN का मालिक फ़ॉरवर्डिंग भूमिका का समर्थन करता है। अगर नहीं, तो क्लाइंट-साइड राउटिंग इसे समर्थित नहीं बनाती।

अनुबंध के दो पक्ष हैं: शाखा और मुख्यालय

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

वापसी का रास्ता वह हिस्सा है जो छूट जाता है। क्लाइंट के लिए टनल पता उसके पीछे का सबनेट घोषित नहीं करता, इसलिए मुख्यालय के राउटरों को उस प्रीफ़िक्स के लिए VPN गेटवे की ओर इशारा करने वाला रूट चाहिए।

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

राउटेड या अनुवादित: वापसी का रास्ता जानबूझकर चुनें

राउटेड चुनें जब प्रति-डिवाइस पहचान और प्रति-होस्ट नीति मायने रखती हैं और आप हर प्रासंगिक राउटर पर वापसी रूट बनाए रख सकते हैं।

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

एक उपयोगी जाँच असममित है: शाखा डिवाइस से कोई संसाधन माँगें, फिर पुष्टि करें कि जवाब मुख्यालय से शाखा प्रीफ़िक्स की ओर निकलता है। traceroute -n 10.60.4.20 मुख्यालय के होस्ट से दिखाता है कि वह रास्ता VPN गेटवे से होकर जाता है या नहीं।

इसे लॉगिन की तरह नहीं, बुनियादी ढाँचे की तरह चलाएँ

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

इस व्यवस्था की तुलना समर्थित साइट गेटवे से उन्हीं आवश्यकताओं के तहत करें, फिर प्रतिबद्ध हों। पुराने डेस्कटॉप का पुन: उपयोग रखरखाव या रिकवरी का काम नहीं हटाता, और सेकंड-हैंड कीमत परिचालन लागत नहीं बताती।

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