जेव्हा दूरस्थ प्रवेश क्लायंटला शाखा गेटवे म्हणून काम करावे लागते

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

प्रोटोकॉल लेबल तुम्हाला काय सांगत नाही

OpenVPN कनेक्टर संपूर्ण सबनेट फॉरवर्ड करणारी साइट-ते-साइट रचना दस्तऐवजीकरण करतो, आणि Access Server ती गेटवे भूमिका व स्पष्ट राउटिंगसह अंमलात आणतो। SSL VPN म्हणून विकले जाणारे दुसरे उत्पादन क्लायंटच्या मागील नेटवर्कची घोषणा करण्याचा समर्थित मार्ग नसताना केवळ दूरस्थ-वापरकर्ता कार्ये देऊ शकते। आवृत्तीही महत्त्वाची आहे, कारण एका आवृत्तीतील वैशिष्ट्य दुसऱ्याबद्दलचे वचन नाही। तुम्ही प्रत्यक्ष चालवत असलेली अंमलबजावणी वाचा, आणि दुसऱ्या उत्पादनासाठी लिहिलेल्या पाककृतीकडे रचना नव्हे, संकेत म्हणून पहा।

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

कराराला दोन बाजू आहेत: शाखा आणि मुख्यालय

शाखेच्या बाजूला एक होस्ट फॉरवर्डिंग, फिल्टरिंग आणि पुनर्प्राप्तीचा मालक आहे। त्याला प्रत्येक शाखा उपकरणापासून हेतुपूर्वक मार्ग हवा, आणि टनेल बंद असतानाही बाह्य VPN कनेक्शन अंतर्निहित नेटवर्कमार्फत पोहोचण्यायोग्य राहिले पाहिजे। मुख्यालयाच्या बाजूला कोणीतरी शाखा सबनेट परिभाषित केला पाहिजे, गेटवेची ओळख स्वीकारली पाहिजे आणि विशिष्ट संसाधनांना परवानगी दिली पाहिजे। कोणताही अर्धा भाग एकटा काम करत नाही।

परतीचा मार्ग हा वगळला जाणारा भाग आहे। क्लायंटसाठी टनेल पत्ता त्याच्या मागील सबनेटची घोषणा करत नाही, म्हणून मुख्यालयाच्या राउटरना त्या प्रीफिक्ससाठी VPN गेटवेकडे निर्देश करणारा मार्ग हवा।

राउटेड रचनेत, केंद्रक शाखा प्रीफिक्सचे पॅकेट फॉरवर्ड करते आणि वरच्या LAN च्या राउटिंगला उत्तरे कशी परत पाठवायची हे माहीत असते। भाषांतरित रचनेत, मुख्यालय जो स्रोत पाहते तो पुन्हा लिहिला जातो, ज्यामुळे एका परतीच्या मार्गाची गरज दूर होऊ शकते पण कोणत्या शाखा मशीनने रहदारी पाठवली हे लपते। ती तडजोड रचना दस्तऐवजातील आहे, कारण भाषांतर सुरू होताच अनुप्रयोग लॉग आणि प्रवेश नियम प्रति-उपकरण ओळख गमावतात।

राउटेड किंवा भाषांतरित: परतीचा मार्ग जाणीवपूर्वक निवडा

प्रति-उपकरण ओळख आणि प्रति-होस्ट धोरण महत्त्वाचे असतील आणि प्रत्येक संबंधित राउटरवर परतीचा मार्ग राखू शकत असाल तर राउटेड निवडा।

मार्ग जोडू शकत नसाल पण मुख्यालय एकच स्रोत पत्ता पाहते हे स्वीकारू शकत असाल तर भाषांतरित निवडा। मिश्र रचना अस्तित्वात आहेत आणि त्यांच्याबद्दल विचार करणे कठीण आहे, म्हणून कोणते प्रीफिक्स राउटेड आणि कोणते भाषांतरित आहेत ते लिहा। नंतर टनेल स्थितीवर विश्वास ठेवण्याऐवजी दोन्ही टोकांवर कॅप्चरने निवड तपासा।

उपयुक्त तपासणी असममित आहे: शाखा उपकरणाकडून संसाधन मागा, नंतर उत्तर मुख्यालय सोडून शाखा प्रीफिक्सकडे जाते याची खात्री करा। traceroute -n 10.60.4.20 मुख्यालयातील होस्टवरून तो मार्ग VPN गेटवेमधून जातो का हे दाखवते।

हे लॉगिनसारखे नव्हे, पायाभूत सुविधेसारखे चालवा

कोणीही लॉगिन नसताना गेटवे कसा सुरू होतो, प्रमाणित करतो, अद्ययावत होतो आणि पुनर्प्राप्त होतो हे ठरवा। क्रेडेन्शियल नूतनीकरण, बहु-घटक सूचना, झोपेचे वर्तन आणि शाखेचा प्रवेश गेल्यावर कोण प्रतिसाद देतो हे सर्व कार्यमूलक प्रश्न बनतात। एक नेटवर्क मार्ग सामायिक करणाऱ्या अनेकांनी गेटवे वापरकर्त्याचे वैयक्तिक विशेषाधिकार वारसा म्हणून घेऊ नयेत, म्हणून संसाधन अधिकृतता, लॉगिंग व्याप्ती आणि अयशस्वी धोरणाला नामनिर्देशित मालक हवा। प्रत्येक उपकरणाची नोंदणी टाळण्यासाठी खाते सामायिक करणे ही रचना नाही।

या रचनेची तुलना समर्थित साइट गेटवेशी समान आवश्यकतांखाली करा, नंतर वचनबद्ध व्हा। जुन्या डेस्कटॉपचा पुनर्वापर देखभाल किंवा पुनर्प्राप्तीचे काम काढून टाकत नाही, आणि सेकंद-हाताची किंमत कार्यमूलक खर्च वर्णन करत नाही।

मंजूर योजनेअंतर्गत इच्छित शाखा अनुप्रयोग, त्यांची परतीची रहदारी आणि एक नाकारलेले गंतव्य सत्यापित करा। यश हे नामनिर्देशित शाखा ओळख आणि स्पष्ट धोरण असलेल्या स्वतःच्या नेटवर्क सेवेसारखे दिसते, कनेक्टेड असे सांगणाऱ्या क्लायंट विंडोसारखे नाही।