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 संरचना दस्तऐवज पुन्हा लोड करता येणाऱ्या सेटिंग्ज आणि येथे वर्णन केलेली पत्ता मर्यादा समाविष्ट करते, आणि उत्पादनातील काहीही फिरवण्यापूर्वी ते पूर्ण वाचणे योग्य आहे.