एक OpenVPN क्लाइंट को निकालना: kill, deny या सर्टिफिकेट रद्द करना?
OpenVPN की तीन क्रियाएँ क्लाइंट को हटाती हैं, लेकिन हर एक कुछ अलग खत्म करती है: चालू सत्र, एक लॉगिन प्रयास, या दोबारा जुड़ने का अधिकार। पहचान के आधार पर चुनें।
आपके नोट्स में एक 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 hold | Where it came from | What it can act on |
|---|---|---|
| Common name | CLIENT_LIST, or the auth hook | kill, and credential revocation |
| Client ID | status on the management socket | client-kill, that one session |
| Tunnel address | ROUTING TABLE, client-connect environment | Nothing 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 से पुष्टि करें, और जब उत्तर को सत्र से अधिक टिकना हो तो क्रेडेंशियल परत ठीक करें।