Nebula സർട്ടിഫിക്കറ്റ് റീലോഡ് IP മാറ്റിയില്ല: കാരണം ഇതാണ്
ഓവർലേ വിലാസം അതേപടി നിൽക്കുമ്പോൾ മാത്രമാണ് റീലോഡ് ഹോസ്റ്റ് ക്രെഡൻഷ്യലുകൾ വീണ്ടും വായിക്കുന്നത്. വിലാസം മാറ്റുന്നത് റീസ്റ്റാർട്ടും നെറ്റ്‌വർക്ക് മാറ്റവുമാണ്, വീണ്ടും ശ്രമിക്കലല്ല.
വേറെ ഓവർലേ വിലാസത്തോടെ പുതിയ ഹോസ്റ്റ് സർട്ടിഫിക്കറ്റ് പുറപ്പെടുവിച്ച്, അത് പഴയ ഫയലിന് മുകളിൽ പകർത്തി, റീലോഡ് അയച്ചാൽ, ഹോസ്റ്റ് മുൻപത്തെ വിലാസത്തിൽ തന്നെ മറുപടി നൽകുന്നു. സ്വാഭാവിക പ്രതികരണം റീലോഡ് പരാജയപ്പെട്ടു അല്ലെങ്കിൽ തെറ്റായ ഫയൽ വായിച്ചു എന്ന് കരുതുകയാണ്. സാധാരണയായി രണ്ടും സംഭവിച്ചിട്ടില്ല: പ്രവർത്തിക്കുന്ന പ്രോസസ് തനിക്ക് ഇതിനകം ഉള്ള ഐഡന്റിറ്റി ബോധപൂർവം നിലനിർത്തി, കാരണം പകരം വയ്ക്കൽ റീലോഡിന് പ്രയോഗിക്കാനാകാത്ത എന്തോ മാറ്റി.
Nebula-യുടെ PKI റീലോഡ് പിന്തുണ ഈ പരിധിയോടെയാണ് രേഖപ്പെടുത്തിയിരിക്കുന്നത്, അതേ രേഖകൾ മറ്റ് മാറ്റങ്ങൾക്ക് റീലോഡ് പ്രവർത്തിക്കുന്നു എന്ന് കാണിക്കുമ്പോൾ ഇത് വിട്ടുപോകാൻ എളുപ്പമാണ്.
റീലോഡ് യഥാർത്ഥത്തിൽ എന്താണ് വീണ്ടും വായിക്കുന്നത്
SSH കീ പോലെയുള്ള കേവലം ക്രെഡൻഷ്യൽ അല്ല ഹോസ്റ്റ് സർട്ടിഫിക്കറ്റ്. അത് ഓവർലേ വിലാസം, ഹോസ്റ്റ് പേര്, ഗ്രൂപ്പ് അംഗത്വങ്ങൾ, സാധുതാ കാലയളവ് എന്നിവ വഹിക്കുന്നു, ഇവയെല്ലാം CA-യുടെ ഒപ്പിലൂടെ ബന്ധിപ്പിച്ചിരിക്കുന്നു. തന്നെ എങ്ങനെ അവതരിപ്പിക്കണം, ഏത് നിയമങ്ങൾ ബാധകമാണ് എന്നിവ തീരുമാനിക്കാൻ ഡീമൺ ആ ഒപ്പിട്ട ഉള്ളടക്കം ഉപയോഗിക്കുന്നു.
റീലോഡ് പ്രോസസിന് തന്റെ ടണലുകൾ നഷ്ടപ്പെടുത്താതെ പുതുക്കിയ ക്രെഡൻഷ്യലുകൾ സ്വീകരിക്കാൻ അനുവദിക്കുന്നു, ഇത് പതിവ് റൊട്ടേഷന് വിലപ്പെട്ടതാണ്: അതേ വിലാസം, അതേ പേര്, അതേ ഗ്രൂപ്പുകൾ, പിന്നീടുള്ള കാലഹരണം. നിയന്ത്രണം ഐഡന്റിറ്റി അതേപടി നിൽക്കണം എന്നതാണ്. ഓവർലേ വിലാസം മാറ്റിയാൽ റീലോഡ് പാതയ്ക്ക് അത് പ്രയോഗിക്കാനാവില്ല, കാരണം വിലാസം പ്രവർത്തിക്കുന്ന ഇൻസ്റ്റൻസ് ഇതിനകം സമ്മതിച്ച കാര്യത്തിന്റെ ഭാഗമാണ്.
അതിനാൽ കണ്ട പെരുമാറ്റം രേഖപ്പെടുത്തിയ പരിധി തന്റെ ജോലി ചെയ്യുന്നതാണ്, നിശബ്ദ പരാജയമല്ല. ഡിസ്കിലെ ഫയൽ പുതിയതാണ്; മെമ്മറിയിലെ ഐഡന്റിറ്റി പഴയതാണ്; റീസ്റ്റാർട്ട് ഇല്ലാതെ ആ വ്യത്യാസം പരിഹരിക്കാൻ പ്രോസസിന് പിന്തുണയുള്ള വഴിയില്ല.
വിലാസവും പേരും ഗ്രൂപ്പുകളും ഒരേ ഐഡന്റിറ്റിയാണ്
സർട്ടിഫിക്കറ്റിനെ സ്വതന്ത്രമായി തിരുത്താവുന്ന ഫീൽഡുകളുടെ കൂട്ടമായല്ല, ഒരു രേഖയായി കാണാൻ സഹായിക്കുന്നു. വിലാസം നീക്കുന്നത് ഒരു മുൻഗണന മാറ്റുന്നതുപോലെയല്ല, കാരണം വിലാസം മറ്റ് ഹോസ്റ്റുകളുടെ പിയർ കോൺഫിഗറേഷനുകളിലും സേവന ബൈൻഡിംഗുകളിലും ഐഡന്റിറ്റിക്കെതിരെ എഴുതിയ നയങ്ങളിലും പ്രത്യക്ഷപ്പെടുന്നു.
| 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 എൻട്രി വായിക്കുന്നു, താൽക്കാലിക ഡയറക്ടറിയിൽ ഇൻസ്റ്റാൾ ചെയ്ത സർട്ടിഫിക്കറ്റ് ഒന്നിനെയും ബാധിക്കുന്നില്ല. പ്രവർത്തിക്കുന്ന കമാൻഡ് ലൈനിലെ പാത പരിശോധിക്കുക, നിങ്ങൾ പിന്തുടർന്ന രേഖയിലെ പാതയല്ല. രണ്ടും വ്യത്യസ്തമാണെങ്കിൽ സർട്ടിഫിക്കറ്റിൽ തൊടാതെ തന്നെ നിങ്ങൾ പ്രശ്നം കണ്ടെത്തി.
പുതിയ സർട്ടിഫിക്കറ്റിന് വേറെ വിലാസമാണെങ്കിൽ, പ്രോസസ് പഴയത് നിലനിർത്തിയെങ്കിൽ, ഇപ്പോൾ നിങ്ങൾക്ക് ദുരൂഹതയല്ല, വിശദീകരണമാണ്. സ്വീകാര്യമെങ്കിൽ അത് റീസ്റ്റാർട്ട് ചെയ്യുക, വിലാസ മാറ്റത്തെ ആകസ്മികമല്ലാത്ത, ആസൂത്രിത നെറ്റ്‌വർക്ക് മാറ്റമായി കാണുക.
വിലാസ മാറ്റം നെറ്റ്‌വർക്ക് മാറ്റമാണ്
ഒരു മെഷീൻ മാറ്റുന്നത് ആസൂത്രണം ചെയ്യുന്നതുപോലെ ഇത് ആസൂത്രണം ചെയ്യുക. മറ്റ് ഹോസ്റ്റുകൾ പഴയ വിലാസം അവരുടെ കോൺഫിഗറേഷനിൽ പിൻ ചെയ്തിരിക്കാം, സേവനങ്ങൾ അതിനോട് വ്യക്തമായി ബന്ധിപ്പിച്ചിരിക്കാം, ഫയർവാൾ നിയമങ്ങൾ അതിനെതിരെ എഴുതിയിരിക്കാം. സർട്ടിഫിക്കറ്റ് മാറ്റുന്നത് ഹോസ്റ്റിനെ നീക്കുന്നു, ഹോസ്റ്റ് നീക്കുന്നത് മറ്റെവിടെയുള്ള ഊഹങ്ങളെ അസാധുവാക്കുന്നു.
ഇത് ചെയ്യുമ്പോൾ രണ്ടാമത്തെ മാനേജ്മെന്റ് പാത ലഭ്യമായി സൂക്ഷിക്കുക, കാരണം നിങ്ങൾ തടസ്സപ്പെടുത്തുന്നത് ഒരുപക്ഷേ ഓവർലേ കണക്ഷൻ തന്നെയാകാം. തകർക്കാൻ പോകുന്ന ടണലിന് മുകളിലൂടെ ഇത് ചെയ്യുന്നത് അഞ്ച് മിനിറ്റ് മാറ്റത്തെ സ്ഥലസന്ദർശനമാക്കി മാറ്റാനുള്ള പരമ്പരാഗത വഴിയാണ്.
റീസ്റ്റാർട്ട് സ്വീകാര്യമാണോ എന്നത് ഹോസ്റ്റ് എന്ത് ചെയ്യുന്നു എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു, അത് സാങ്കേതികമല്ലാത്ത ഷെഡ്യൂളിംഗ് ചോദ്യമാണ്. ഓപ്ഷണൽ അല്ലാത്തത്, റീലോഡ് അഞ്ചാം തവണ അയയ്ക്കുന്നതിനുപകരം റീസ്റ്റാർട്ട് ആവശ്യകത അംഗീകരിക്കുക എന്നതാണ്.
പഴയ ക്രെഡൻഷ്യൽ വേറെയായി ഒഴിവാക്കുക
ഒരു മെഷീനിൽ പകരം ഇൻസ്റ്റാൾ ചെയ്യുമ്പോൾ, ഓരോ പിയറും തനിക്ക് ഇതിനകം അറിയാവുന്ന ക്രെഡൻഷ്യലിൽ വിശ്വസിക്കുന്നത് തുടരുന്നു. മാറ്റത്തിന്റെ കാരണം കോംപ്രമൈസ് ആയിരുന്നെങ്കിൽ, പഴയ ഐഡന്റിറ്റി വിശ്വാസം അല്ലെങ്കിൽ ബ്ലോക്ക്ലിസ്റ്റ് നടപടിക്രമത്തിലൂടെ ഒഴിവാക്കണം, എങ്കിൽ മാത്രമേ പിയറുകൾ അത് യഥാർത്ഥത്തിൽ നിരസിക്കുകയുള്ളൂ.
ഇത് സ്വന്തം സ്ഥിരീകരണമുള്ള വേറെ ഘട്ടമാണ്: പുതിയ ഫയൽ ജോലി ചെയ്തു എന്ന് കരുതുന്നതിനുപകരം, പഴയ ഐഡന്റിറ്റി ഇനി പ്രവർത്തിക്കുന്നില്ല എന്ന് മറ്റൊരു ഹോസ്റ്റിൽ നിന്ന് സ്ഥിരീകരിക്കുക. Nebula PKI കോൺഫിഗറേഷൻ രേഖ റീലോഡ് ചെയ്യാവുന്ന ക്രമീകരണങ്ങളും ഇവിടെ വിവരിച്ച വിലാസ പരിധിയും ഉൾക്കൊള്ളുന്നു, ഉത്പാദനത്തിൽ എന്തെങ്കിലും റൊട്ടേറ്റ് ചെയ്യുന്നതിന് മുമ്പ് അത് പൂർണ്ണമായി വായിക്കുന്നത് മൂല്യവത്താണ്.