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यदि लुकअप टनल की ओर इशारा करता है, तो वितरण काम कर गया और बाकी समस्या कहीं और है। यदि यह डिफ़ॉल्ट गेटवे की ओर इशारा करता है, तो रूट इंस्टॉल नहीं हुआ, क्लाइंट-साइड विकल्प द्वारा फ़िल्टर हो गया, या ऐसी प्रोफ़ाइल का है जिसे क्लाइंट इस्तेमाल नहीं करता।
मान लें कि वितरण काम कर गया और फिर भी कुछ जवाब नहीं देता: तब गेटवे पर फ़ॉरवर्डिंग, दूसरी ओर का वापसी रूट और उनके बीच का कोई भी फ़ायरवॉल जाँचें। रूट रास्ता चुनता है, वह पहुँच नहीं देता।