रद्द गरिएको क्लाइन्ट अझै जोडिन्छ: सूची कहिल्यै पुगेन
रद्द गर्नु प्रमाणपत्र प्रमाणीकरणको इनपुट हो, सत्र अन्त्य गर्ने आदेश होइन। नयाँ जडान र चलिरहेको टनेलले सूचीलाई कसरी देख्छन् भन्ने तुलना गर्नुहोस्।
रद्द गर्नु कहिल्यै चलिरहेको टनेलभित्र पसी सत्र मेटाउँदैन। सूची प्रमाणपत्र प्रमाणीकरणको इनपुट हो र TLS सत्र सुरु गर्ने नियन्त्रण च्यानलको आदानप्रदानमा यो हेरिन्छ। यही एउटा तथ्यले दुवै आश्चर्य बुझाउँछ: रद्द गरिएको क्लाइन्ट फेरि जोडिन्छ, किनकि सूची कहिल्यै प्रमाणककहाँ पुगेन, र अहिलेको सत्र टिकिरहन्छ, किनकि कसैले पनि केही पनि फेरि प्रमाणित गरेन।
सूची इनपुट हो, कार्य होइन
सत्र स्थापना गर्दा सर्भरले क्लाइन्ट प्रमाणपत्रलाई आफ्ना विश्वास एङ्करविरुद्ध मान्य गर्छ, र रद्द गर्ने निर्देशनले त्यो निर्णयमा सूची खोज थप्छ। जाँच सर्भरमा हुन्छ, त्यसैले क्लाइन्टले आफ्नो प्रमाणपत्र रद्द भएको देख्न सक्दैन र त्यही प्रमाणपत्र दिइरहन्छ। त्यसैले अझै जोडिने प्रोफाइलले कुनै प्रमाणकले शृंखला स्वीकार गरेको मात्र प्रमाणित गर्छ, रद्द गर्नु असफल भयो भनेर होइन।
सूची आफैं जारी मिति र अर्को अद्यावधिक मिति भएको हस्ताक्षरित वस्तु हो। असम्बन्धित सूची, अर्को अधिकारीले हस्ताक्षर गरेको सूची वा अर्को अद्यावधिक मिति बितिसकेको सूची हालको सूचीको विकल्प होइन, र पुरानो सूची अस्वीकार गरिन्छ कि चुपचाप स्वीकार गरिन्छ भन्ने तैनाथीमा निर्भर छ।
नयाँ जडान र चलिरहेको सत्र
रद्द गर्नु सत्र स्थापना वा फेरि वार्ता हुँदा मूल्याङ्कन गरिन्छ, प्रत्येक प्याकेटमा डेटा च्यानलविरुद्ध होइन। पहिले नै जोडिएको क्लाइन्टसँग ट्राफिक कुञ्जीहरू हुन्छन्, त्यसैले उसको प्रमाणपत्र सूचीमा देखिएपछि पनि उसले प्याकेट पास गरिरहन्छ। पूर्वनिर्धारित पुनर्वार्ता अन्तराल घण्टामा मापन गरिन्छ, त्यसैले अद्यावधिक सूची नयाँ आउनेहरूका लागि लागू हुन सक्छ, चलिरहेको टनेल भने रहिरहन्छ।
| Situation | What the list does | When it applies |
|---|---|---|
| Fresh connection | Blocks the handshake | At verification, immediately |
| Renegotiation | Blocks the new exchange | At the next renegotiation interval |
| Established data channel | Nothing | Until the session ends |
तत्काल कार्यान्वयनका लागि सूची मात्र होइन, जानाजान गरिएको कार्य चाहिन्छ। सेवा पुनः सुरु गर्दा प्रत्येक क्लाइन्ट फेरि जोडिन बाध्य हुन्छ, तर व्यवस्थापन इन्टरफेसबाट एउटा सत्र अन्त्य गर्दा अरू अछुत रहन्छन्। प्रत्येक घटनाका लागि एउटा छान्नुहोस् र कुन प्रयोग गर्नुभयो लेख्नुहोस्। दुवै विकल्पको प्रभावक्षेत्र फरक छ, र त्यही साँचो निर्णय हो।
प्रमाणकले साँच्चै पढ्ने फाइल पुर्याउनुहोस्
सूची अधिकारीको अभिलेखबाट बनाई त्यसपछि प्रमाणपत्र प्रमाणित गर्ने प्रत्येक मेसिनमा प्रतिलिपि गर्नुपर्छ। यसलाई CA होस्टमा बनाई सर्भरमा कहिल्यै नराख्नु सबैभन्दा सामान्य असफलता हो, र यो ठ्याक्कै बिग्रेको रद्द गर्ने सुविधाजस्तो देखिन्छ।
ca ca.crt
cert server.crt
key server.key
crl-verify /etc/openvpn/crl.pemफाइल साँच्चै पढिन्छ कि भन्ने दुई विवरणले निर्धारण गर्छ। सापेक्ष मार्ग कन्फिगरेसन निर्देशिकाको सापेक्ष हल गरिन्छ, त्यसैले अपरेटरको घरमा छाडिएको प्रति कहिल्यै भेटिन सक्दैन। र डेमन सुरु भएपछि सामान्यतया विशेषाधिकार छाड्छ, त्यसैले रनटाइम खातालाई प्रत्येक मूल निर्देशिकामा खोज अनुमति र फाइलमा पढ्ने अनुमति चाहिन्छ। दुवैलाई root ले होइन, रनटाइम खाताले जाँच्नुहोस्, नत्र परीक्षणले गलत कुरा प्रमाणित गर्छ।
systemd होस्टमा कडा गरिएको युनिटले पनि बाटो लुकाउन सक्छ, पढ्ने-मात्र दृश्य वा सुरक्षित प्रणाली निर्देशिकाद्वारा। सेवाभित्रबाट यो हराएको फाइलबाट छुट्याउन सकिँदैन, त्यसैले अनुमति त्रुटि खोज्न जानुअघि युनिटका प्रतिबन्ध जाँच्नुहोस्। फाइलको मोडलाई दोष दिनुअघि युनिट फाइल पढ्नुहोस्।
क्लाइन्टमा होइन, सर्भरमा पुष्टि गर्नुहोस्
सर्भर लगले के भयो भन्छ: सूची खोल्नु, लोड गर्नु वा रद्द गरिएको क्रम सङ्ख्यासँग प्रमाणीकरण असफल हुनु। क्लाइन्टले सामान्य ह्यान्डशेक असफलता मात्र जनाउँछ, त्यसैले रद्द गर्ने निर्णय खोज्न क्लाइन्ट लग नराम्रो ठाउँ हो।
रद्द गरिएको प्रोफाइलबाट नयाँ प्रयाससँग प्रमाणित गर्नुहोस् र त्यसपछि रोक्नुहोस्। त्यो प्रोफाइलबाट सफल जडान नै फाइलको बाटो र रनटाइम खाता जाँच्ने सङ्केत हो, सूची गलत थियो भनेर अनुमान गर्ने होइन। त्यो सफल प्रयासलाई स्वीकृति परीक्षणका रूपमा राख्नुहोस्, र तपाईंले नदेखेको पुनःजडान गन्नुहुँदैन।
केही पनि रद्द नगर्ने कुरा
ल्यापटपबाट प्रोफाइल मेटाउनु, क्लाइन्टबाट प्रमाणपत्र फाइल हटाउनु वा प्रयोगकर्तालाई जोडिन छोड्न भन्नुले सर्भरमा केही पनि बदल्दैन। अधिकारीले रद्द गरेको अभिलेख नगरेसम्म र प्रमाणकले परिणामस्वरूप सूची नपढेसम्म प्रमाणपत्र मान्य रहन्छ।
त्यसैले शृंखला लेखेर राख्नु फाइदाजनक छ: रद्द गरेको अभिलेख गर्नुहोस्, सूची बनाई हस्ताक्षर गर्नुहोस्, ठ्याक्कै त्यही फाइल वितरण गर्नुहोस्, र सेवा खाताले त्यो पढ्न सक्ने पुष्टि गर्नुहोस्। प्रत्येक कडी छोटो छ, र कुनै पनि कडी छुट्यो भने रद्द गरिएको क्लाइन्ट रमाइलोसँग जोडिइरहन्छ। चार लाइनको जाँचसूची एक लाइन पनि नभएको अनुमानभन्दा राम्रो छ।