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 लिहू शकतो पण डेमन लिहू शकत नाही असा मार्ग प्रत्येक कनेक्शनला लॉगमध्ये अनेक ओळी खाली पुरलेल्या परवानगी त्रुटीसह नकारात बदलतो.

वाटप म्हणजे अधिकृतता नाही: पिन केलेला पत्ता अजूनही सर्व्हरच्या मागील प्रत्येक गंतव्यापर्यंत प्रवेश देत नाही. राउटिंग आणि फायरवॉल धोरण त्याच्या स्वतःच्या स्तरात ठेवा, आणि तुम्ही नुकताच निश्चित केलेल्या पत्त्याविरुद्ध ते पडताळा.