तुमच्या नोंदींमध्ये एक common name आणि एक पत्ता आहे, आणि तीन आदेश जे सर्व क्लायंट काढतात असे दिसतात। फक्त एकच तुम्हाला हवे ते करतो, आणि निवड यावर अवलंबून आहे की तुम्हाला आता चालू असलेले सत्र संपवायचे आहे, पुढील लॉगिन नाकारायचे आहे, की जोडण्याचा अधिकारच पूर्ण काढून घ्यायचा आहे। काहीही स्पर्श करण्यापूर्वी जी ओळख खरोखर तुमच्याकडे आहे ती वाचा, कारण OpenVPN चा तलाव नंतर तोच टनेल पत्ता दुसऱ्या सत्राला देतो।

खरोखर तुमच्याकडे कोणती ओळख आहे

आवृत्ती 3 ची स्थिती फाइल नेहमीची सुरुवात आहे। CLIENT_LIST विभागात common name, खरा पत्ता, बाइट काउंटर आणि जोडण्याची वेळ असते; ROUTING TABLE विभाग व्हर्च्युअल पत्ता common name शी शेवटच्या संदर्भाच्या वेळ-शिक्क्यासह जोडतो। common name हीच स्थिर ओळख आहे। व्हर्च्युअल पत्ता हे वाटप आहे, आणि NAT मागील खरा पत्ता सत्रांदरम्यान बदलू शकतो, सर्व्हरवर काहीही न बदलता।

व्यवस्थापन इंटरफेस त्याच्या status आदेशाने असेच दृश्य दाखवतो आणि प्रत्येक सत्रासाठी क्लायंट ID जोडतो। client-kill नेमक्या त्याच ID ची अपेक्षा करतो, आणि तो टनेल पत्ता नाही। जोडणीच्या वेळी कोणत्या common name ला कोणता पत्ता मिळाला हे जाणून घ्यायचे असेल, तर client-connect स्क्रिप्टच्या पर्यावरणात दोन्ही सोबत विश्वासार्ह बाह्य पत्ताही असतो, पण ती स्क्रिप्ट OpenVPN वापरकर्ता म्हणून चालते आणि तिला लिहिण्यायोग्य लॉग मार्ग हवा असतो।

What you holdWhere it came fromWhat it can act on
Common nameCLIENT_LIST, or the auth hookkill, and credential revocation
Client IDstatus on the management socketclient-kill, that one session
Tunnel addressROUTING TABLE, client-connect environmentNothing durable, the address is recycled

आता मारा, लॉगिनला नकार द्या, कायमचे रद्द करा

व्यवस्थापन इंटरफेस मधील दोन्ही काढण्याचे आदेश सत्र-क्रिया आहेत। kill common name किंवा खरा पत्ता आणि पोर्ट घेतो; client-kill क्लायंट ID घेतो आणि ती प्रत त्वरित संपवतो। दोन्हीपैकी कोणताही अडथळा नाही: वैध सर्टिफिकेट आणि पासवर्ड असलेला काढून टाकलेला क्लायंट काही सेकंदांत पुन्हा जोडतो, जे चाचणी peer पुन्हा वापरताना ठीक आहे आणि लॅपटॉप चोरीला गेल्यावर निरुपयोगी।

client-deny वेगळ्या प्रकारचा निर्णय आहे। सहसा तो authentication किंवा client-connect हुकमधून जारी होतो आणि कारणासह सत्र नाकारतो, त्यामुळे तो लॉगिन नाकारणाऱ्या धोरणाला बसतो, जोडणी तोडणाऱ्याला नाही। दस्तऐवज असेही इशारा देतात की TLS पुनर्वाटाघाटीदरम्यान जारी केलेला नकार पुनर्निर्धारित की अवैध करतो, तर विद्यमान सत्र संक्रमण खिडकी बंद होईपर्यंत चालू राहू शकते। जर आवश्यकता अशी असेल की क्लायंट आता गेला पाहिजे, तर दस्तऐवजी उत्तर client-kill आहे।

टिकाऊ काढणे या सर्वांच्या खाली आहे। सर्टिफिकेट रद्द करा आणि crl-verify अशा यादीकडे निर्देश करतो याची खात्री करा जी सर्व्हर खरोखर पुन्हा लोड करतो, ccd डिरेक्टरीतील क्लायंट-विशिष्ट संरचना फाइल निष्क्रिय करा, किंवा ज्या backend ला authentication हुक विचारतो तिथे खाते निष्क्रिय करा। रद्द करणेही तात्काळ नाही: डीफॉल्ट reneg-sec सेटिंग्जसह प्रस्थापित सत्र पुनर्वाटाघाटीपर्यंत चालू राहू शकते, म्हणून सत्र-क्रिया आणि क्रेडेन्शियल-क्रिया एकमेकांना पूरक आहेत, पर्याय नाहीत।

व्यवस्थापन सॉकेट मोकळे आहे का?

व्यवस्थापन इंटरफेस एका वेळी एका क्लायंटची सेवा करतो। जर GUI किंवा निरीक्षण डेमॉन आधीच जोडणी धरून असेल, तर तुमची स्क्रिप्ट त्याच्या शेजारी जोडू शकत नाही, आणि क्लायंटनुसार तुम्ही स्वच्छ अपयशाऐवजी विद्यमान क्लायंट बाहेर ढकलू शकता। त्याचा पासवर्ड त्याच सॉकेटवर स्पष्ट मजकुरात जातो, म्हणून त्याची जागा स्थानिक पत्ता किंवा unix सॉकेट आहे, कधीही सार्वजनिक इंटरफेस नाही।

जेव्हा तुम्ही सॉकेट घेऊ शकत नाही, तेव्हाही पर्याय आहेत, आणि सर्व हळू आहेत। नियंत्रण असेल तर आधी GUI चे सत्र सोडा, किंवा क्रेडेन्शियल स्तराचा मार्ग स्वीकारा आणि पुढील पुनर्वाटाघाटीची वाट पाहा। जे करू नये ते म्हणजे एक क्लायंट काढून टाकण्यासाठी सेवा पुन्हा सुरू करणे, कारण त्यामुळे बाकीची सर्व सत्रेही संपतात आणि या सत्राचे स्थिती फाइलचे पुरावे नष्ट होतात।

थेट सर्व्हरवर मी चालवतो तो क्रम

जोडा, सध्याची स्थिती वाचा, आत्ता वाचलेल्या ID वर कार्य करा, मग तो पुन्हा वाचा। दस्तऐवजातून कॉपी केलेली मूल्ये चुकीच्या व्यक्तीला मारण्याचा सर्वात सामान्य मार्ग आहेत।

status                     # note the client ID and common name
client-kill 3              # end that session now
kill Test-Client           # alternative: by common name
status                     # confirm the session is gone

वरील नाव आणि क्रमांक प्लेसहोल्डर आहेत, आणि ID इतर क्लायंट डिस्कनेक्ट झाल्यावर पुन्हा वापरले जातात। काहीही पूर्ण म्हणून लिहिण्यापूर्वी ओळ नाही याची खात्री करा, आणि जोडलेल्या क्लायंटची संख्या अनेकांनी नाही तर एकाने बदलली आहे याची तपासणी करा।

तो बाहेरच राहिला याची खात्री करा

common name, टनेल पत्ता, बाह्य पत्ता आणि काढण्याचा मिनिट नोंदवा। जर तोच common name एका मिनिटानंतर पुन्हा दिसला, तर सत्र-क्रिया चालली आणि क्रेडेन्शियल स्तर चालला नाही, जे कधीही अमलात न आलेल्या आदेशाच्या दुरुस्तीपेक्षा पूर्णपणे वेगळे आहे।

मग क्लायंटच्या बाजूने चाचणी करा। रद्द केलेले सर्टिफिकेट पुढील हँडशेकमध्ये अपयशी व्हायला हवे; जर ते तरीही जोडत असेल, तर CRL अजिबात वाचले जात नाही, आणि हाच तो शोध आहे ज्याची नोंद करणे योग्य आहे। काय संपवायचे आहे त्यानुसार क्रिया निवडा, दुसऱ्या status ने खात्री करा, आणि उत्तर सत्रापेक्षा जास्त टिकायचे असेल तेव्हा क्रेडेन्शियल स्तर दुरुस्त करा।

संबंधित लेख