OpenVPN client-connect हुक: आपका पता वास्तव में कहाँ जाता है

client-connect स्क्रिप्ट से पता लौटाना ऐसा लगता है जैसे इसे क्लाइंट का IP सेट करना चाहिए। लेकिन ऐसा नहीं होता: सर्वर तक हुक का एकमात्र मार्ग एक अस्थायी फ़ाइल है जिसका पथ स्क्रिप्ट के अंतिम आर्ग्युमेंट के रूप में आता है, और पता वहाँ ifconfig-push सिंटैक्स में लिखा जाना चाहिए। जो स्क्रिप्ट पता प्रिंट करती है या कुछ भी लिखे बिना शून्य के साथ बाहर निकलती है, वह पूल से मिले पते वाला जुड़ा हुआ क्लाइंट बनाती है, और सर्वर लॉग पूरी तरह स्वस्थ दिखता है।

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

हुक फ़ाइल लिखता है, लौटाया गया मान नहीं

घोषणा दो पंक्तियों की है: कॉल की अनुमति देने के लिए script-security 2, फिर client-connect /etc/openvpn/server/assign-address.sh. जब कोई क्लाइंट प्रमाणित होता है, तो सर्वर उस स्क्रिप्ट को बनाई गई फ़ाइल-पथ को अंतिम आर्ग्युमेंट के रूप में जोड़कर चलाता है, जो $1 केवल तभी होता है जब घोषणा अपने कोई अतिरिक्त आर्ग्युमेंट न भेजे। उस क्लाइंट पर लागू होने वाली हर बात उस फ़ाइल में सामान्य निर्देशों के रूप में, प्रति पंक्ति एक, ठीक वैसे ही जाती है जैसे वे किसी कॉन्फ़िगरेशन में दिखाई देते। अपने पैरामीटर जोड़ने वाला रैपर स्थिति को खिसका देता है, और क्लासिक लक्षण ऐसी स्क्रिप्ट है जो --verbose जैसे दिखने वाले पथ पर लिखती है।

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

दो निर्देश ध्यान देने योग्य हैं क्योंकि वे बाकी सब के साथ परस्पर क्रिया करते हैं। ifconfig-push पता तय करता है, जबकि भेजा गया route क्लाइंट को बताता है कि टनल के माध्यम से क्या पहुँच योग्य है; पहला लौटाएँ और दूसरा भूल जाएँ तो आपको पता तो है पर जाने की जगह नहीं वाला क्लाइंट मिलता है। फ़ाइल के भीतर क्रम मायने नहीं रखता, पर पूर्णता रखती है। ऐसे प्रीफ़िक्स के लिए रूट भेजने वाला हुक जहाँ कोई पीयर पहुँच नहीं सकता, दूसरे छोर से देखी गई वही गलती है।

इनपुट पर्यावरण चर के माध्यम से आते हैं: common_name, trusted_ip, ifconfig_pool_remote_ip और बाकी। इन सबको सर्वर के बाहर की स्ट्रिंग मानें, कभी शेल के टुकड़े नहीं।

पता मैपिंग एक नीति है, अंकगणित नहीं

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

जो नाम नियंत्रित करता है वह पता नियंत्रित करता है, इसलिए तय करें कि इस परिनियोजन में common_name वास्तव में क्या दर्शाता है। username-as-common-name सक्षम होने पर पहचान लॉगिन है, प्रमाणपत्र का विषय नहीं। उस मान को कभी शेल मूल्यांकन में न भेजें, और क्लाइंट को कभी फ़ाइल पथ प्रभावित न करने दें।

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

टोपोलॉजी तय करती है कि ifconfig-push का क्या अर्थ है

10.77.0.0/24 पर topology subnet के साथ, ifconfig-push 10.77.0.20 255.255.255.0 एक पता और उसका नेटमास्क है। topology net30 के अंतर्गत दूसरा आर्ग्युमेंट नेटमास्क बिल्कुल नहीं बल्कि पीयर पता है, इसलिए सबनेट का रूप net30 सर्वर पर कॉपी करने से आपको ऐसा क्लाइंट मिलता है जो जुड़ता है और ट्रैफ़िक पास नहीं कर सकता। टोपोलॉजी जानबूझकर बदलें, कभी इसलिए नहीं कि उदाहरण सुसंगत दिखे। जो सर्वर पहले से net30 चला रहा है उसके पुराने एड्रेसिंग पर जीवित क्लाइंट हैं, इसलिए बदलाव एक रखरखाव विंडो वाला माइग्रेशन है, एक पंक्ति का संपादन नहीं।

स्थिर पते गतिशील पूल के बाहर और हर दूसरे स्थिर आवंटन के बाहर होने चाहिए, जिनमें सामान्य client-config-dir फ़ाइलों द्वारा दिए गए पते भी शामिल हैं। यदि दो तंत्र अलग-अलग क्लाइंट के लिए एक ही पता उत्पन्न कर सकते हैं, तो उनमें से एक अंततः ऐसा करेगा।

इस पर भरोसा करने से पहले चार मामले जाँचें

वही जाँचें मैप की गई पहचान, बिना मैप की गई पहचान, पुनः कनेक्शन और अनुकरणीय रजिस्ट्री विफलता पर चलाएँ। openvpn --config client.ovpn --verb 4 पुश उत्तर में आवंटित पता दिखाता है, और सर्वर पर grep -A2 PUSH_REPLY /var/log/openvpn/openvpn.log पुष्टि करता है कि वास्तव में क्या भेजा गया। बिना मैप की गई पहचान के लिए अपेक्षित परिणाम अस्वीकृत कनेक्शन है, पूल का पता नहीं।

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

आवंटन प्राधिकरण नहीं है: पिन किया गया पता अभी भी सर्वर के पीछे हर गंतव्य तक पहुँच नहीं देता। रूटिंग और फ़ायरवॉल नीति को अपनी अलग परत में रखें, और इसे उस पता के विरुद्ध सत्यापित करें जिसे आपने अभी तय किया है।