Nebula ब्लॉकलिस्ट: इसे वितरित करें, लाइटहाउस नहीं करेगा

ब्लॉकलिस्ट का प्रवर्तन जाँच करने वाले होस्ट का गुण है, जाँचे जा रहे प्रमाणपत्र का नहीं। जिस मशीन ने वह प्रविष्टि कभी लोड नहीं की, वह पहचान को स्वीकार करता रहता है, और हैंडशेक में कुछ भी आपको चेतावनी नहीं देता कि दो पीयर असहमत हैं। एक ही उजागर क्रेडेंशियल के लिए सस्ता उपाय और महँगा उपाय पहुँच और प्रतिवर्तीयता में भिन्न हैं, इसलिए सोच-समझकर चुनें। नीचे के अनुभाग बताते हैं कि प्रविष्टि क्या करती है, उसे कहाँ पहुँचाना है, रोटेशन कब बेहतर उत्तर है, और यह कैसे सिद्ध करें कि इनमें से कोई एक काम कर गया।

ब्लॉकलिस्ट प्रविष्टि वास्तव में क्या करती है

PKI कॉन्फ़िगरेशन ऐसे फिंगरप्रिंट सूचीबद्ध करता है जिन्हें होस्ट को अस्वीकार करना होता है, भले ही प्रमाणपत्र वैध रूप से हस्ताक्षरित और समाप्त न हुआ हो। प्रवर्तन स्थानीय रूप से होता है, उस सूची के विरुद्ध जो उस होस्ट ने सेवा शुरू होने पर लोड की थी। प्रविष्टि के बारे में कुछ भी प्रमाणपत्र के भीतर यात्रा नहीं करता, इसलिए पीयर उसे दिखाए गए क्रेडेंशियल से निर्णय नहीं सीख सकता। इसीलिए लाइटहाउस की यहाँ कोई भूमिका नहीं है: लाइटहाउस पीयर को एक-दूसरे को खोजने में और जहाँ सीधा रास्ता विफल हो वहाँ ट्रैफ़िक रिले करने में मदद करते हैं। वे खोज और रिले परत हैं, कॉन्फ़िगरेशन वितरण चैनल नहीं।

एक मशीन को अद्यतन करना उस मशीन के निर्णय बदल देता है और हर दूसरे पीयर को ठीक वैसा ही छोड़ देता है। जो पीयर हस्ताक्षर करने वाली प्राधिकरण पर भरोसा करता है और उसने प्रविष्टि कभी नहीं देखी, उसके पास कुछ भी अस्वीकार करने का कारण नहीं है। इसलिए लाइटहाउस को देखकर निरसन का परीक्षण कुछ भी सिद्ध नहीं करता, क्योंकि जिस घटक को आप देख रहे हैं, उससे सूची लागू करने के लिए कभी नहीं कहा गया।

प्रमाणपत्र की पहचान करें, उपकरण की नहीं

उस क्रेडेंशियल का फिंगरप्रिंट उपयोग करें जिसे आप अस्वीकार करना चाहते हैं, क्योंकि मेज़बान नाम, उपकरण लेबल या वर्तमान पता आज एक मशीन की पहचान करता है और अगले महीने कुछ और। इनमें से कोई भी स्ट्रिंग ब्लॉकलिस्ट में नहीं दिखती, और इनमें से कोई भी पुनःस्थापन के बाद नहीं बचती। प्रमाणपत्र प्रिंट करें, फिंगरप्रिंट पढ़ें, और जाँचें कि वह सेवानिवृत्त किए जा रहे क्रेडेंशियल का है, उसके प्रतिस्थापन का नहीं। जब प्रतिस्थापन पहले ही जारी हो चुका हो तो दोनों फ़ाइलें पढ़ना महत्वपूर्ण है, क्योंकि पुराना और नया प्रमाणपत्र एक नाम साझा कर सकते हैं और हर दूसरे क्षेत्र में भिन्न हो सकते हैं।

कौन-सा फिंगरप्रिंट कब ब्लॉक हुआ, यह दर्ज करें, ताकि बाद की लेखा-परीक्षा पूर्ण हुए परिवर्तन को इच्छित परिवर्तन से अलग कर सके। यह भी नोट करें कि प्रविष्टि क्या नहीं करती: वह हस्ताक्षर करने वाले प्राधिकरण को अमान्य नहीं करती, और वह उस प्राधिकरण से भविष्य के प्रमाणपत्र को स्वीकार होने से नहीं रोकती। होस्ट प्रमाणपत्र को ब्लॉक करना और किसी समझौते-विहीन प्राधिकरण को बदलना अलग-अलग कार्य हैं जिनके परिणाम भी अलग हैं।

nebula-cert print -path /etc/nebula/host.crt
pki:
  blocklist:
    - "a1b2c3d4e5f6"

इसे किसी भी अन्य कॉन्फ़िगरेशन की तरह वितरित करें

सूची को एक वितरण तंत्र वाले कॉन्फ़िगरेशन की तरह मानें, न कि ऐसी फ़ाइल की तरह जिसे कोई याद आने पर संपादित करता है। पूरी सूची भेजें, डेल्टा नहीं, ताकि जिस होस्ट ने पहले का अद्यतन चूका वह अंतराल जमा करने के बजाय एकत्रित हो जाए। Nebula PKI दस्तावेज़ ठीक यही सलाह देता है, और उस सलाह का शब्दशः पालन करना उचित है, न कि उसे मैन्युअल प्रक्रिया में बदल देना।

पुष्टि करें कि चल रही सेवा ने सामग्री दोबारा लोड की, केवल यह नहीं कि डिस्क पर फ़ाइल बदल गई। ट्रैक करें कि किन मशीनों ने परिवर्तन लागू किया और बाकी सूची को खाली होने तक दृश्य रखें। एक हफ़्ते के लिए बंद लैपटॉप वह पीयर है जिसने निर्णय कभी नहीं सीखा, और वह ऐसे नेटवर्क से फिर जुड़ सकता है जिसकी किसी को अपेक्षा नहीं थी। फिंगरप्रिंट के बगल में वितरण विधि दर्ज करें, क्योंकि अगला निरसन उसी का पुनः उपयोग करेगा और पहले ही में प्रक्रिया की गड़बड़ियाँ ठीक की जाती हैं।

ब्लॉकलिस्ट या प्राधिकरण रोटेशन

ब्लॉकलिस्ट प्रविष्टि संकीर्ण है: एक पहचान काम करना बंद कर देती है और बाकी सब चलता रहता है। हस्ताक्षर करने वाले प्राधिकरण का रोटेशन व्यापक है: उसके जारी किए हर प्रमाणपत्र पर भरोसा खत्म हो जाता है, और हर होस्ट को नया क्रेडेंशियल और नया विश्वास आधार चाहिए। पहला लक्षित निरसन है और दूसरा एक स्थानांतरण है, इसलिए उन्हें अलग स्वीकृतियाँ और अलग रखरखाव अवधि चाहिए। तालिका दोनों को पहुँच, प्रयास और प्रतिवर्तीयता पर साथ-साथ रखती है।

खोया लैपटॉप ब्लॉकलिस्ट की माँग करता है, क्योंकि नुकसान का दायरा एक पहचान है और यदि आपने गलत फिंगरप्रिंट ब्लॉक किया तो परिवर्तन प्रतिवर्ती है। लीक हुई प्राधिकरण कुंजी रोटेशन की माँग करती है, क्योंकि ब्लॉकलिस्ट उन प्रमाणपत्रों में मदद नहीं कर सकती जो अभी जारी नहीं हुए। इन अतियों के बीच, पूछें कि क्या उजागर क्रेडेंशियल कुछ और हस्ताक्षरित कर सकता था, क्योंकि एक प्राधिकरण एक होस्ट से अधिक है।

घटना से पहले निर्णय लिख लें, क्योंकि दबाव में चुनाव करने पर डिफ़ॉल्ट रूप से व्यापक विकल्प निकलता है। आप जो भी मार्ग चुनें, बचा हुआ कार्य समान है: यह सिद्ध करना कि जिन होस्ट की बात मायने रखती है उन पर प्रवर्तन हुआ। उसी क्षण फिंगरप्रिंट और तारीख दर्ज करना ही बाद में प्रमाण संभव बनाता है।

अस्वीकृति और शेष को सत्यापित करें

ब्लॉक की गई पहचान से जुड़ें और विफलता की पुष्टि करें, फिर अधिकृत पीयर से जुड़ें और पुष्टि करें कि वह अभी भी अपनी आवश्यकता तक पहुँचता है। जो परिवर्तन सबको तोड़ दे वह सफल निरसन नहीं है। दोनों नए सत्रों से करें, क्योंकि कैशे की गई स्थिति परिणाम छिपा सकती है।

जाँचें कि परिवर्तन के बाद स्थापित सत्र समाप्त होता है या नहीं, और फ़ाइल संपादित करने से कुछ समाप्त हो जाता है ऐसा मानने के बजाय अपने संस्करण और कॉन्फ़िगरेशन के लिए व्यवहार नोट करें। disconnect_invalid विकल्प उन क्लाइंट को कवर करता है जिनके प्रमाणपत्र समाप्त या अमान्य हैं, इसलिए उस पर भरोसा करने से पहले पुष्टि करें कि वह आपके मामले पर कैसे लागू होता है। यदि तत्काल समाप्ति आवश्यकता है, तो उसे विशेष रूप से परखें और जो देखा उसे दर्ज करें। फिर पुनः आरंभ के बाद परीक्षण दोहराएँ, क्योंकि जो होस्ट सूची को केवल अगले रीबूट तक लागू करता है, उसकी वितरण समस्या है जिसे पहले परीक्षण ने छिपाया था। स्वस्थ लाइटहाउस आपको बताता है कि खोज काम करती है, यह नहीं कि किसी पीयर ने नीति लागू की।