Nebula ब्लकलिस्ट: यसलाई वितरण गर्नुहोस्, लाइटहाउसले गर्दैन
ब्लकलिस्ट प्रविष्टि त्यसलाई लोड गर्ने होस्टमा मात्र लागू हुन्छ। सूचीको वितरणलाई CA घुमाउनेसँग तुलना गर्नुहोस्, त्यसपछि अस्वीकृत पियर र काम गर्ने पियर जाँच्नुहोस्।
ब्लकलिस्टको कार्यान्वयन जाँच गर्ने होस्टको गुण हो, जाँचिने प्रमाणपत्रको होइन। प्रविष्टि कहिल्यै नलोड गरेको मेसिनले पहिचान स्वीकार गर्न जारी राख्छ, र ह्यान्डसेकमा दुई पियर असहमत छन् भन्ने कुनै पनि चेतावनी दिँदैन। एउटै खुलासा भएको प्रमाण-पत्रका लागि सस्तो र महँगो उपाय दायरा र उल्टाउन सकिने क्षमतामा फरक पर्छन्, त्यसैले जानाजान छनोट गर्नुहोस्। तलका खण्डहरूले प्रविष्टिले के गर्छ, यसलाई कहाँ पुर्याउनुपर्छ, घुमाउने कहिले राम्रो उत्तर हो, र दुईमध्ये एउटा काम गरेको कसरी प्रमाणित गर्ने भन्ने समेट्छ।
ब्लकलिस्ट प्रविष्टिले वास्तवमा के गर्छ
प्रमाणपत्र वैध रूपमा हस्ताक्षरित र म्याद नसकिएको भए पनि होस्टले अस्वीकार गर्नुपर्ने औंलाका छापहरू PKI कन्फिगरेसनले सूचीबद्ध गर्छ। कार्यान्वयन स्थानीय रूपमा, सेवा सुरु हुँदा होस्टले लोड गरेको सूचीविरुद्ध हुन्छ। प्रविष्टिबारे केही पनि प्रमाणपत्रभित्र यात्रा गर्दैन, त्यसैले पियरले आफूलाई देखाइएको प्रमाण-पत्रबाट निर्णय सिक्न सक्दैन। त्यसैले यहाँ लाइटहाउसको कुनै भूमिका छैन: लाइटहाउसहरूले पियरहरूलाई एकअर्कालाई भेट्टाउन र सिधा मार्ग असफल हुने ठाउँमा ट्राफिक अगाडि पठाउन मद्दत गर्छन्। तिनीहरू खोज र अगाडि पठाउने तह हुन्, कन्फिगरेसन वितरणको च्यानल होइन।
एउटा मेसिन अद्यावधिक गर्दा त्यस मेसिनका निर्णय बदलिन्छन् र अन्य हरेक पियर ठ्याक्कै अघिजस्तै रहन्छ। हस्ताक्षर गर्ने अधिकारमा भरोसा गर्ने र प्रविष्टि कहिल्यै नदेखेको पियरलाई केही अस्वीकार गर्ने कारण हुँदैन। त्यसैले लाइटहाउस हेरेर रद्दीकरण परीक्षण गर्नु केही पनि प्रमाणित गर्दैन, किनकि तपाईंले हेरिरहनुभएको घटकलाई सूची कार्यान्वयन गर्न कहिल्यै भनिएको थिएन।
प्रमाणपत्र पहिचान गर्नुहोस्, उपकरण होइन
तपाईंले अस्वीकार गर्न चाहेको प्रमाण-पत्रको औंलाको छाप प्रयोग गर्नुहोस्, किनकि होस्टनाम, उपकरण लेबल वा हालको ठेगानाले आज एउटा मेसिन पहिचान गर्छ र अर्को महिना अरू केही। तीमध्ये कुनै पनि स्ट्रिङ ब्लकलिस्टमा देखिँदैन, र तीमध्ये कुनै पनि पुनःस्थापनापछि टिक्दैन। प्रमाणपत्र प्रिन्ट गर्नुहोस्, औंलाको छाप पढ्नुहोस्, र त्यो सेवानिवृत्त हुँदै गरेको प्रमाण-पत्रको हो, यसको प्रतिस्थापनको होइन भनी जाँच्नुहोस्। प्रतिस्थापन पहिले नै जारी भइसकेको छ भने दुवै फाइल पढ्नु महत्त्वपूर्ण हुन्छ, किनकि पुरानो र नयाँ प्रमाणपत्रले नाम साझा गर्न सक्छन् र अरू हरेक क्षेत्रमा फरक हुन सक्छन्।
कुन औंलाको छाप कहिले ब्लक भयो भनी अभिलेख गर्नुहोस्, ताकि पछिको लेखापरीक्षणले पूरा भएको परिवर्तनलाई इच्छित परिवर्तनबाट छुट्याउन सकोस्। प्रविष्टिले के गर्दैन भन्ने पनि टिप्नुहोस्: यसले हस्ताक्षर गर्ने अधिकारलाई अमान्य गर्दैन, र त्यो अधिकारको भविष्यको प्रमाणपत्र स्वीकार हुनबाट रोक्दैन। होस्टको प्रमाणपत्र ब्लक गर्नु र सम्झौता भएको अधिकार प्रतिस्थापन गर्नु फरक परिणाम भएका फरक कार्यहरू हुन्।
nebula-cert print -path /etc/nebula/host.crt
pki:
blocklist:
- "a1b2c3d4e5f6"अरू कुनै पनि कन्फिगरेसनजस्तै यसलाई वितरण गर्नुहोस्
सूचीलाई कसैले सम्झेपछि सम्पादन गर्ने फाइलको रूपमा होइन, वितरण संयन्त्र भएको कन्फिगरेसनको रूपमा लिनुहोस्। डेल्टाको सट्टा पूरै सूची पठाउनुहोस्, ताकि अघिल्लो अद्यावधिक छुटेको होस्टले खाडल जम्मा गर्नुको सट्टा मिलेर जाओस्। Nebula PKI कागजातले ठ्याक्कै त्यही सिफारिस गर्छ, र सल्लाहलाई म्यानुअल प्रक्रियामा परिणत गर्नुको सट्टा शब्दशः पालना गर्न योग्य छ।
चलिरहेको सेवाले सामग्री पुनः लोड गरेको पुष्टि गर्नुहोस्, डिस्कमा फाइल मात्र बदलिएको होइन। कुन मेसिनहरूले परिवर्तन लागू गरे त्यसको ट्र्याक राख्नुहोस् र बाँकी सूची रित्तो नहुँदासम्म देखिने राख्नुहोस्। एक हप्ता बन्द ल्यापटप निर्णय कहिल्यै नसिकेको पियर हो, र कसैले नअपेक्षा गरेको नेटवर्कबाट यो फेरि जोडिन सक्छ। औंलाको छापको छेउमा वितरण विधि अभिलेख गर्नुहोस्, किनकि अर्को रद्दीकरणले त्यही पुनः प्रयोग गर्छ र पहिलोमै प्रक्रिया डिबग हुन्छ।
ब्लकलिस्ट वा अधिकार घुमाउने
ब्लकलिस्ट प्रविष्टि साँघुरो हुन्छ: एउटा पहिचानले काम गर्न छोड्छ र बाँकी सबै जारी रहन्छ। हस्ताक्षर गर्ने अधिकार घुमाउनु फराकिलो हुन्छ: यसले जारी गरेको हरेक प्रमाणपत्र अविश्वासनीय हुन्छ, र हरेक होस्टलाई नयाँ प्रमाण-पत्र र नयाँ विश्वासको आधार चाहिन्छ। पहिलो लक्षित रद्दीकरण हो र दोस्रो स्थानान्तरण हो, त्यसैले तिनलाई फरक स्वीकृति र फरक मर्मत अवधि चाहिन्छ। तालिकाले दुवैलाई दायरा, प्रयास र उल्टाउन सकिने क्षमतामा छेउछाउ राख्छ।
| Question | Blocklist entry | Authority rotation |
|---|---|---|
| What stops working | One identity | Every certificate from that authority |
| Fleet work | Push one file and confirm a reload | New credentials and a new trust anchor everywhere |
| Reversible | Yes, remove the line | No, the old authority stays distrusted |
| Fits | A lost or stolen device | A leaked authority key |
हराएको ल्यापटपका लागि ब्लकलिस्ट उपयुक्त हुन्छ, किनकि क्षतिको दायरा एउटा पहिचान हो र गलत औंलाको छाप ब्लक गरेको भए परिवर्तन उल्टाउन सकिन्छ। चुहिएको अधिकारको कुञ्जीका लागि घुमाउनु आवश्यक हुन्छ, किनकि अझै जारी नभएका प्रमाणपत्रहरूमा ब्लकलिस्टले मद्दत गर्न सक्दैन। ती दुई चरमबीच, खुलासा भएको प्रमाण-पत्रले अरू केही हस्ताक्षर गर्न सक्थ्यो कि भनी सोध्नुहोस्, किनकि अधिकार एउटा होस्टभन्दा ठूलो हुन्छ।
घटना अघि निर्णय लेख्नुहोस्, किनकि दबाबमा छनोट गर्दा पूर्वनिर्धारित रूपमा फराकिलो विकल्प निस्कने गर्छ। तपाईंले जुनसुकै मार्ग लिनुभए पनि बाँकी काम उही हो: महत्त्वपूर्ण होस्टहरूमा कार्यान्वयन भएको प्रमाणित गर्नु। त्यही क्षणमा औंलाको छाप र मिति अभिलेख गर्नु नै पछि प्रमाण सम्भव बनाउँछ।
अस्वीकृति र बाँकी जाँच्नुहोस्
ब्लक गरिएको पहिचानबाट जोडिनुहोस् र असफलता पुष्टि गर्नुहोस्, त्यसपछि अधिकृत पियरबाट जोडिनुहोस् र यो अझै आफूलाई चाहिने ठाउँमा पुग्छ भनी पुष्टि गर्नुहोस्। सबैलाई तोड्ने परिवर्तन सफल रद्दीकरण होइन। दुवै नयाँ सत्रबाट गर्नुहोस्, किनकि क्यास गरिएको अवस्थाले नतिजा लुकाउन सक्छ।
परिवर्तनपछि स्थापित सत्र अन्त्य हुन्छ कि भनी जाँच्नुहोस्, र फाइल सम्पादन गर्दा केही रोकिन्छ भनी मान्नुको सट्टा आफ्नो संस्करण र कन्फिगरेसनका लागि व्यवहार अभिलेख गर्नुहोस्। disconnect_invalid विकल्पले म्याद सकिएका वा अमान्य प्रमाणपत्र भएका ग्राहकहरू समेट्छ, त्यसैले यसमा भर पर्नुअघि यो तपाईंको अवस्थामा कसरी लागू हुन्छ पुष्टि गर्नुहोस्। तत्काल अन्त्य आवश्यकता भए त्यसलाई छुट्टै परीक्षण गर्नुहोस् र देखेको कुरा अभिलेख गर्नुहोस्। त्यसपछि पुनःसुरु गरेपछि परीक्षण दोहोर्याउनुहोस्, किनकि सूची अर्को रिबुटसम्म मात्र कार्यान्वयन गर्ने होस्टमा पहिलो परीक्षणले लुकाएको वितरण समस्या हुन्छ। स्वस्थ लाइटहाउसले खोजी काम गर्छ भन्छ, कुनै पियरले नीति लागू गर्यो भनेर होइन।