तपाईंको नोटमा एउटा 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 ले पुष्टि गर्नुहोस्, र उत्तर सत्रभन्दा लामो टिक्नुपर्ने बेला प्रमाण-तह सुधार्नुहोस्।

सम्बन्धित लेखहरू