OpenVPN मध्ये रूट कुठे असावा: क्लायंटमध्ये की सर्व्हरमध्ये?
सर्व्हर कॉन्फिगमधील नग्न रूट सर्व्हर बदलते, क्लायंट नाही। क्लायंट फाइल, जागतिक push किंवा एका क्लायंटसाठी push निवडा आणि काय पोहोचले ते तपासा।
तुम्ही सर्व्हर कॉन्फिगरेशनमध्ये route 10.60.0.0 255.255.255.0 जोडता, पुन्हा सुरू करता, लॅपटॉप पुन्हा जोडता, आणि त्या लॅपटॉपवरून सबनेट अजूनही पोहोचण्यायोग्य नाही। ओळ स्वीकारली गेली, सेवा स्वच्छ सुरू झाली, आणि लॉगमध्ये काहीही चुकीचे दिसत नाही। जे घडले ते म्हणजे तुम्ही संपादित केलेल्या मशीनवरच रूट इंस्टॉल झाला: गेटवे आता त्या प्रीफिक्सपर्यंत पोहोचू शकतो असे मानतो, तर क्लायंटला काहीही सांगण्यात आले नाही। स्थान हाच संपूर्ण प्रश्न आहे, आणि तीच ओळ राहू शकते अशी चार ठिकाणे आहेत।
चार ठिकाणे आणि प्रत्येकाला कोण मिळते
रूट क्लायंटच्या स्वतःच्या कॉन्फिगरेशनने जोडता येतो, जागतिक push द्वारे प्रत्येक क्लायंटला देऊ केला जातो, क्लायंट-विशिष्ट फाइलद्वारे एका क्लायंटला देऊ केला जातो, किंवा सर्व्हरच्या स्वतःच्या राउटिंग संदर्भात लिहिला जातो।
ती चार प्रकरणे जवळजवळ समान सिंटॅक्स वापरतात आणि पूर्णपणे भिन्न परिणाम देतात। पहिली तीन क्लायंट टनेलमध्ये काय पाठवतो यावर परिणाम करतात; चौथे सर्व्हर नेटवर्कपर्यंत कसा पोहोचतो यावर परिणाम करते, जे सर्व्हरला स्वतःला मार्ग आवश्यक असताना उपयुक्त आणि वितरण समजल्यास हानिकारक असते।
ओळ लिहिण्यापूर्वी चारपैकी कोणता हवा हे ठरवा, नंतर प्राप्तकर्त्याची पुष्टी करा।
| Placement | Effect | Receiver |
|---|---|---|
| Client profile route | Installed by the client at connect | That client only |
Global push "route ..." | Sent to every client that accepts pushed options | All pulling clients |
| Client-specific push | Sent to the matching client context | One identity |
| Server config route, no push | Added to the server's own table | The gateway itself |
नग्न सर्व्हर रूट लोकांना का चकित करतो
सर्व्हर कॉन्फिगरेशन हे प्रशासक प्रथम पाहतात ते ठिकाण आहे, आणि तिथले रूट निर्देश VPN नेटवर्कबद्दलचे विधान असे वाचले जाते। तसे नाही। OpenVPN त्याला डेमॉन चालू असलेल्या मशीनवरील स्थानिक रूट इंस्टॉल मानते, जो तुम्ही ip route ने करून नंतर विसराल तसाच बदल आहे।
वितरणासाठी रूट push करणे आवश्यक आहे, आणि push साठी क्लायंटने तो ओढणे आवश्यक आहे। ओढलेले पर्याय बंद करून सुरू केलेला क्लायंट ऑफर पूर्णपणे दुर्लक्षित करतो। सर्व्हर फाइल पुन्हा लिहिण्यापूर्वी त्या हस्तांदोलनाची दोन्ही टोके तपासा, कारण सर्व्हरचा लॉग तक्रार करणार नाही: त्याच्या बाजूने ऑफर पाठवली गेली। स्वीकारलेला रूटही पुढील कनेक्शनवरच लागू होतो, तुम्ही आधीच असलेल्या सत्रात कधीही नाही।
दोन्ही स्वतंत्र क्रिया म्हणून पाहिल्यावर अपयश रहस्यमय राहत नाही: सर्व्हर प्रीफिक्सपर्यंत पोहोचतो, क्लायंट पोहोचू शकत नाही, आणि दोन्ही विधाने एकाच वेळी खरी आहेत।
प्रति-क्लायंट फाइली आणि त्या जुळणारी ओळख
क्लायंट-विशिष्ट फाइलला सर्व्हरने प्रमाणित केलेल्या ओळखीचे नाव दिले जाते, जे डीफॉल्टनुसार प्रमाणपत्राचे सामान्य नाव असते। डेस्कटॉप क्लायंटमधील मैत्रीपूर्ण कनेक्शन नाव ते मूल्य नाही, आणि जुळणी न झाल्यास कधीही न वाचली जाणारी फाइल तयार होते।
सर्व्हर प्रत्यक्षात वापरत असलेली डिरेक्टरी तपासा, नंतर फाइलचे नाव प्रमाणित ओळखीशी अगदी जुळते याची पुष्टी करा, मोठी आणि लहान अक्षरे धरून।
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/त्या फाइलमध्येही रूट push करावा लागतो, कारण प्रति-क्लायंट संदर्भ त्या क्लायंटच्या सत्रावर लागू केलेल्या पर्यायांचा संच आहे, स्थानिक राउटिंग टेबल नाही। तिथला नग्न रूट जागतिक फाइलमधील नग्न रूटसारखाच प्रश्न निर्माण करतो।
क्लायंटची स्वतःची फाइल आणि तिचा मालक साधन
क्लायंटच्या कॉन्फिगमध्ये ठेवलेला रूट तो क्लायंट जोडला जातो तेव्हा इंस्टॉल होतो आणि डिस्कनेक्ट झाल्यावर काढला जातो, जे स्थिर गंतव्यासाठी योग्य जीवनचक्र आहे।
जर नेटवर्क मॅनेजर प्रोफाइलचा मालक असेल, तर तो ते पर्याय एकदा आयात करून नंतर स्वतःची प्रत ठेवू शकतो। नंतर डाउनलोड केलेली फाइल संपादित केल्याने काहीही बदलत नाही, हे "रूट आहे पण लागू होत नाही" याचे सामान्य कारण आहे।
तुम्ही डाउनलोड केलेल्या फाइलऐवजी सक्रिय प्रोफाइल तपासा, आणि मॅनेजर दाखवत असलेल्या आयात केलेल्या सेटिंग्ज तपासा। नंतर कनेक्ट होऊन एखादा विशिष्ट पत्ता कोणता मार्ग वापरतो हे सिस्टमला विचारा, रूट मजकूर फाइलमध्ये होता म्हणून टनेल जिंकली असे गृहीत धरण्याऐवजी।
क्लायंटवर पडताळा, नंतर परतीचा मार्ग तपासा
गंतव्याबद्दल क्लायंटच्या स्वतःच्या राउटिंग टेबलला विचारा, सर्व्हरच्या नाही। प्रीफिक्समधील एका होस्टसाठी शोध हा कोणता इंटरफेस आणि पुढील हॉप वापरले जाईल हे दाखवण्यासाठी पुरतो।
ip route get 10.60.0.10शोध टनेलकडे निर्देश करत असल्यास वितरण काम करून झाले आणि उर्वरित समस्या इतरत्र आहे। तो डीफॉल्ट गेटवेकडे निर्देश करत असल्यास, रूट इंस्टॉल झाला नाही, क्लायंट-साइड पर्यायाने फिल्टर केला गेला, किंवा क्लायंट वापरत नसलेल्या प्रोफाइलचा आहे।
वितरण काम करून झाले आणि तरीही काही प्रतिसाद देत नाही असे गृहीत धरा: तेव्हा गेटवेवरील फॉरवर्डिंग, पलीकडील बाजूचा परतीचा मार्ग आणि त्यांच्यामधील कोणताही फायरवॉल तपासा। रूट मार्ग निवडतो, तो प्रवेश देत नाही।