OpenVPN client-connect अपयश: disconnect वेळी स्वच्छता हमी आहे का?
नाकारलेला क्लायंट फायरवॉल नियम किंवा लिहिलेला नोंद परत घेत नाही. कॉलबॅक कराराची तुलना तुमच्या hook ने स्वतः करावयाच्या रोलबॅकशी करा.
जेव्हा client-connect स्क्रिप्ट शून्य नसलेल्या कोडसह बाहेर पडते, तेव्हा OpenVPN क्लायंट नाकारते, आणि ऑपरेटर सहसा समजतात की संबंधित client-disconnect स्क्रिप्ट सर्व आवरून काढेल. बऱ्याचदा ती कधीच चालत नाही, कारण disconnect प्रक्रिया connect टप्प्याला काय पूर्ण करता आले यावर अवलंबून असते. नाकारणे आणि रोलबॅक एकच यंत्रणा मानणे हेच अपयशी लॉगिनला गळलेला फायरवॉल नियम किंवा अनाथ नोंद बनवते. ही दोन वेगळी जबाबदारी आहेत, आणि त्यापैकी फक्त एक स्वयंचलित आहे. सर्व्हरवर स्थिती सोडल्याचा आरोप करण्यापूर्वी hook चा स्वतःचा निर्गम मार्ग वाचा.
शून्य नसलेले निर्गमन क्लायंट नाकारते; ते तुमचे काम परत घेत नाही
client-connect ची निर्गमन स्थिती प्रवेशाचा निर्णय आहे. शून्य म्हणजे प्रवेश, बाकी काहीही म्हणजे इन्स्टन्स पूर्णपणे प्रस्थापित होण्यापूर्वी तोडून टाकणे. त्या करारात स्क्रिप्टने बाहेरील जगात आधीच काय केले आहे याची तपासणी करणारे काहीही नाही. स्क्रिप्टने iptables नियम जोडला, ओळ लिहिली किंवा काउंटर वाढवला असेल, तर ते बदल नाकारण्यानंतरही टिकतात.
तीच असमानता प्लगइन्सनाही लागू होते, जिथे एका इन्स्टन्ससाठी अनेक connect फंक्शन्स चालू शकतात. नंतरचे अपयश आधीचे यश मागेपुढे रद्द करत नाही, आणि आधीच्या फंक्शनला सहोदर फंक्शन अपयशी ठरले हे कळण्याचा मार्ग नाही.
नाकारणे स्वयंचलित, स्वच्छता नाही
OpenVPN 2.6 पुस्तिका client-disconnect प्रक्रियेला आधीच्या connect प्रक्रियेच्या यशाशी जोडते. दस्तऐवजीकृत अपवाद कास्केड साखळ्यांना व्यापतो: एक connect पायरी आधीच यश परत दिली असेल, तर नंतरची connect पायरी अपयशी ठरली तरी इन्स्टन्स तोडताना संबंधित disconnect पायऱ्या तरी चालतात. तो अपवाद अरुंद आहे आणि किती कॉलबॅक संरचित आहेत यावर अवलंबून आहे, म्हणून एक shell स्क्रिप्ट तपासून साखळीबद्दल तुम्हाला काहीच कळत नाही.
रचना करण्यापूर्वी प्रत्यक्ष संरचना नकाशावर उतरवा: कोणती स्क्रिप्ट, कोणते प्लगइन आणि कोणत्या क्रमाने चालतात. खालील तक्ता अर्धवट सेटअप काय मागे ठेवतो ते सूचीबद्ध करतो.
| What the hook did before failing | What the client sees | What stays behind |
|---|---|---|
| Created a firewall entry | A rejection, with no tunnel | A rule matching an address nobody owns |
| Wrote a state row | A rejection, with no tunnel | A record of a session that never started |
| Allocated a tunnel address | A rejection, with no tunnel | An address marked busy until something releases it |
प्रत्येक ओळ क्लायंटसाठी एकाच पद्धतीने आणि होस्टसाठी वेगळ्या पद्धतीने संपते. त्यापैकी कोणती घडली हे क्लायंटला सांगता येत नाही, म्हणून hook ने अपयशाची स्थिती परत देण्यापूर्वी केलेले उलटवले पाहिजे.
अपयशी स्क्रिप्टच्या आत भरपाई करा
सामायिक स्थितीला स्पर्श करण्यापूर्वी शक्य ते सर्व पडताळा: प्रमाणपत्राची क्षेत्रे, पत्त्याची उपलब्धता, क्लायंट ज्या गटाचा आहे तो गट. सर्वात स्वस्त नाकारणे म्हणजे कोणत्याही वाटपापूर्वी घडणारे. सेटअप अनेक बाह्य क्रियांवर पसरला की कोणत्या पूर्ण झाल्या याची नोंद ठेवा आणि अपयशाची स्थिती परत देण्यापूर्वी त्या उलट क्रमाने परत घ्या.
एक ठोस उदाहरण: स्क्रिप्ट प्रत्येक क्लायंटसाठी फायरवॉल नोंद तयार करते, नंतर तिचे वर्णन करणारी स्थिती-ओळ लिहिण्यात अपयशी ठरते. अपयशी शाखेने नुकतीच तयार केलेली नोंद काढून टाकावी आणि नंतर शून्य नसलेल्या कोडसह बाहेर पडावे. कधीही नियोजित न होणाऱ्या disconnect घटनेची वाट पाहणे हाच नियम त्याच्या उद्दिष्ट सत्रापेक्षा जास्त जगण्याचा मार्ग आहे.
भरपाई इडेंपोटेंट आणि मालकीची करा
स्वच्छता दोनदा चालवण्यास सुरक्षित आणि काय हटवू शकते याबद्दल अचूक असली पाहिजे. आधीच्या प्रयत्नातील उशिरा आलेली घटना केवळ दोन्हींचे सामायिक नाव किंवा पुनर्वापर केलेला बोगदा पत्ता असल्यामुळे नव्या सत्राचे वाटप काढून टाकू नये. विशिष्ट हँडल किंवा ऑपरेशन आयडी संसाधनासह नोंदवा, आणि नावाने नव्हे, त्या किल्लीने हटवा. डेटाबेस व्यवहार केवळ डेटाबेसच्या स्वतःच्या बदलांमध्ये मदत करतात; त्या सीमेबाहेरील फायरवॉल नियमाला स्पष्ट भरपाई पायरी हवी असते.
प्रक्रिया बदल आणि स्वच्छता यामधील अंतरात मरू शकते असे गृहीत धरा, आणि वेळापत्रकानुसार बाह्य स्थितीची स्वीकृत क्लायंट यादीशी तुलना करणारा समेटकार जोडा.
प्रत्यक्षात वेगळे असलेले तीन मार्ग तपासा
तीन प्रसंगांचा सराव करा: काहीही वाटप होण्यापूर्वीचे नाकारणे, अर्धवट वाटपानंतरचे नाकारणे, आणि नंतर संपणारे सामान्य स्वीकृत सत्र. ते तीन वेगळ्या लॉग ओळी आणि वेगळे अवशेष निर्माण करतात. प्रत्येकानंतर बाह्य स्थिती तपासा, केवळ क्लायंटचा अपयश संदेश नाही, कारण तीनपैकी दोनमध्ये क्लायंटचे अपयश हेच अपेक्षित परिणाम आहे.
hook चा टप्पा, निर्गमन स्थिती आणि काय वाटप झाले किंवा सोडले गेले ते ओळखपत्रे वगळून नोंदवा. स्वतः तयार केलेल्या संसाधनाचे नाव घेणारा hook लॉग हाच गळलेला नियम सहा महिन्यांनंतर शोधण्यायोग्य बनवतो.