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 कन्फिगरेसन कागजात ले पुनः लोड गर्न सकिने सेटिङहरू र यहाँ वर्णन गरिएको ठेगाना सीमा समेट्छ, र उत्पादनसँग सम्बन्धित कुनै पनि कुरा घुमाउनुअघि यो पूरै पढ्न योग्य छ।