Nebula प्रमाणपत्र का पुनः लोड IP नहीं बदल सका: कारण यह है
पुनः लोड होस्ट क्रेडेंशियल को तभी दोबारा पढ़ता है जब overlay पता वही रहता है। पता बदलने का मतलब है पुनः आरंभ और नेटवर्क परिवर्तन, दोबारा कोशिश नहीं।
आप अलग overlay पते के साथ नया होस्ट प्रमाणपत्र जारी करते हैं, उसे पुरानी फ़ाइल पर कॉपी करते हैं, पुनः लोड भेजते हैं, और होस्ट पहले वाले पते पर ही उत्तर देता रहता है। स्वाभाविक प्रतिक्रिया यह मानना है कि पुनः लोड विफल रहा या गलत फ़ाइल पढ़ी गई। आमतौर पर दोनों में से कुछ नहीं हुआ: चल रही प्रक्रिया ने जानबूझकर वही पहचान बनाए रखी जो उसके पास पहले से थी, क्योंकि प्रतिस्थापन ने ऐसा कुछ बदला जिसे पुनः लोड लागू नहीं कर सकता।
Nebula का PKI पुनः लोड समर्थन इसी सीमा के साथ प्रलेखित है, और जब वही दस्तावेज़ दिखाता है कि पुनः लोड अन्य परिवर्तनों के लिए काम करता है, तब इसे चूकना आसान है।
पुनः लोड वास्तव में क्या दोबारा पढ़ता है
होस्ट प्रमाणपत्र केवल क्रेडेंशियल नहीं है जैसे SSH कुंजी होती है। यह overlay पता, होस्ट नाम, समूह सदस्यता और वैधता अवधि वहन करता है, और ये सब CA के हस्ताक्षर से एक साथ बंधे होते हैं। डेमॉन उस हस्ताक्षरित सामग्री का उपयोग यह तय करने के लिए करता है कि वह स्वयं को कैसे प्रस्तुत करे और उस पर कौन से नियम लागू होते हैं।
पुनः लोड प्रक्रिया को उसकी सुरंगें गिराए बिना नवीनीकृत क्रेडेंशियल लेने देता है, जो नियमित रोटेशन के लिए मूल्यवान है: वही पता, वही नाम, वही समूह, बाद में समाप्ति। बाधा यह है कि पहचान वही रहनी चाहिए। overlay पता बदलिए और पुनः लोड पथ उसे लागू नहीं कर सकता, क्योंकि पता उस चीज़ का हिस्सा है जिसके लिए चल रहा इंस्टेंस पहले ही प्रतिबद्ध हो चुका है।
इसलिए जो व्यवहार आपने देखा वह प्रलेखित सीमा अपना काम कर रही है, मौन विफलता नहीं। डिस्क पर फ़ाइल नई है; मेमोरी में पहचान पुरानी है; प्रक्रिया के पास पुनः आरंभ के बिना उस अंतर को सुलझाने का कोई समर्थित तरीका नहीं है।
पता, नाम और समूह एक ही पहचान हैं
प्रमाणपत्र को अलग-अलग संपादन योग्य फ़ील्ड के समूह के बजाय एक ही रिकॉर्ड मानना सहायक है। पता हटाना वरीयता बदलने जैसा नहीं है, क्योंकि पता अन्य होस्ट के पीयर कॉन्फ़िगरेशन, सेवा बाइंडिंग और पहचान के विरुद्ध लिखी नीतियों में दिखता है।
| Field | What changes when you replace it |
|---|---|
| Overlay address | Peers that pinned the old address, service bindings, and any rule written against it |
| Host name | Name-based policy and the identities other hosts expect to see |
| Groups | Which access rules match, even if the address stays identical |
| Validity window | Nothing structural, which is why renewal reloads cleanly |
समूह अपनी अलग पंक्ति के हक़दार हैं क्योंकि वे उसी उलझन का अधिक शांत संस्करण पैदा करते हैं। जो होस्ट अपना पता रखता है पर समूह बदल देता है, वह पुनः आरंभ के बाद भिन्न सेवाओं तक पहुँच सकता है, और केवल पुराने पते पर ping करने वाला परीक्षण पूरी तरह स्वस्थ दिखेगा जबकि नीचे पहुँच निर्णय बदल चुके होंगे। केवल पहुँच नहीं, किसी नियम के अधीन एक सेवा जाँचिए। सुरंग की पुष्टि और नीति की पुष्टि के बीच यही अंतर है।
लोड किए गए प्रमाणपत्र की प्रतिस्थापन से तुलना करें
डेमॉन ने फ़ाइल अनदेखी की है, यह मानने से पहले दोनों पढ़िए। जो प्रमाणपत्र आप लोड करना चाहते हैं उसे प्रिंट करें और जिन फ़ील्ड को आपने बदला माना है उन्हें सत्यापित करें, फिर सत्यापित करें कि चल रहा कॉन्फ़िगरेशन उसी पथ की ओर इशारा करता है, कहीं और की प्रति की ओर नहीं।
nebula-cert print -path /etc/nebula/host.crt
systemctl status nebula
ps -o args= -p $(pgrep -f 'nebula -config' | head -1)प्रक्रिया के आर्ग्युमेंट लोगों की अपेक्षा से अधिक मायने रखते हैं। -config /etc/nebula/config.yml भेजने वाली यूनिट उस फ़ाइल की pki.cert प्रविष्टि पढ़ती है, और किसी अस्थायी निर्देशिका में स्थापित प्रमाणपत्र कुछ भी प्रभावित नहीं करता। चल रही कमांड लाइन में पथ जाँचिए, आपने जिस दस्तावेज़ का पालन किया उसका पथ नहीं। यदि दोनों अलग हैं तो आपने प्रमाणपत्र को छुए बिना ही समस्या खोज ली है।
यदि नए प्रमाणपत्र का पता अलग है और प्रक्रिया ने पुराना रखा है, तो अब आपके पास पहेली नहीं, व्याख्या है। यदि स्वीकार्य हो तो इसे पुनः आरंभ करें, और पता परिवर्तन को आकस्मिक नहीं, नियोजित नेटवर्क परिवर्तन मानिए।
पता परिवर्तन नेटवर्क परिवर्तन है
इसे वैसे ही योजनाबद्ध कीजिए जैसे मशीन स्थानांतरित करने की योजना बनाते हैं। अन्य होस्ट पुराने पते को अपने कॉन्फ़िगरेशन में पिन कर चुके होंगे, सेवाएँ उससे स्पष्ट रूप से बंधी होंगी, और फ़ायरवॉल नियम उसके विरुद्ध लिखे गए होंगे। प्रमाणपत्र बदलने से होस्ट हिलता है, और होस्ट हिलने से कहीं और की मान्यताएँ अमान्य हो जाती हैं।
यह करते समय दूसरा प्रबंधन पथ खुला रखिए, क्योंकि हो सकता है कि जो आप बाधित कर रहे हैं वही overlay कनेक्शन हो। जिस सुरंग को आप तोड़ने वाले हैं उसी के ऊपर से यह करना पाँच मिनट के बदलाव को साइट विज़िट में बदलने का पुराना तरीका है।
पुनः आरंभ स्वीकार्य है या नहीं यह इस पर निर्भर है कि होस्ट क्या कर रहा है, और यह तकनीकी नहीं बल्कि समय-निर्धारण का प्रश्न है। जो वैकल्पिक नहीं है वह है पुनः लोड पाँचवीं बार भेजने के बजाय पुनः आरंभ की आवश्यकता को स्वीकार करना।
पुराना क्रेडेंशियल अलग से हटाइए
एक ही मशीन पर प्रतिस्थापन स्थापित करने से हर पीयर अभी भी उस क्रेडेंशियल पर भरोसा करता है जिसे वह पहले से जानता है। यदि परिवर्तन का कारण समझौता था, तो पुरानी पहचान को विश्वास या ब्लॉकलिस्ट प्रक्रिया के माध्यम से हटाना होगा ताकि पीयर वास्तव में उसे अस्वीकार करें।
यह अपने सत्यापन वाला अलग चरण है: नई फ़ाइल ने काम कर दिया मानने के बजाय किसी अन्य होस्ट से पुष्टि कीजिए कि पुरानी पहचान अब काम नहीं करती। Nebula PKI कॉन्फ़िगरेशन दस्तावेज़ पुनः लोड किए जा सकने वाले सेटिंग्स और यहाँ वर्णित पता सीमा को कवर करता है, और उत्पादन से जुड़ी कोई भी चीज़ रोटेट करने से पहले इसे पूरा पढ़ना चाहिए।