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 ഓപ്ഷൻ സർട്ടിഫിക്കറ്റുകൾ കാലഹരണപ്പെട്ടതോ അസാധുവായതോ ആയ ക്ലയന്റുകളെ ഉൾക്കൊള്ളുന്നു, അതിനാൽ അതിനെ ആശ്രയിക്കുന്നതിന് മുമ്പ് നിങ്ങളുടെ കേസിൽ അത് എങ്ങനെ ബാധകമാകുന്നുവെന്ന് സ്ഥിരീകരിക്കുക. തൽക്ഷണ അവസാനം ആവശ്യകതയാണെങ്കിൽ, അത് പ്രത്യേകമായി പരീക്ഷിച്ച് നിങ്ങൾ കണ്ടത് രേഖപ്പെടുത്തുക. തുടർന്ന് പുനരാരംഭത്തിന് ശേഷം പരീക്ഷണം ആവർത്തിക്കുക, കാരണം ലിസ്റ്റ് അടുത്ത റീബൂട്ട് വരെ മാത്രം നടപ്പാക്കുന്ന ഹോസ്റ്റിന് ആദ്യ പരീക്ഷണം മറച്ചുവച്ച ഒരു ഡെലിവറി പ്രശ്നമുണ്ട്. ആരോഗ്യകരമായ ലൈറ്റ്ഹൗസ് കണ്ടെത്തൽ പ്രവർത്തിക്കുന്നുവെന്ന് പറയുന്നു, ഏതെങ്കിലും പിയർ ഒരു നയം പ്രയോഗിച്ചുവെന്നല്ല.