Nebula બ્લોકલિસ્ટ: તેને વિતરિત કરો, લાઇટહાઉસ નહીં

બ્લોકલિસ્ટનો અમલ એ ચકાસણી કરતા હોસ્ટનો ગુણધર્મ છે, ચકાસાતા પ્રમાણપત્રનો નહીં. જે મશીને કદી એ પ્રવેશ લોડ કર્યો નથી તે ઓળખને સ્વીકારવાનું ચાલુ રાખે છે, અને હેન્ડશેકમાં કંઈ પણ તમને ચેતવતું નથી કે બે પીઅર અસહમત છે. એક જ ખુલ્લી ક્રેડન્શિયલ માટે સસ્તો ઉપાય અને મોંઘો ઉપાય વ્યાપ અને ઉલટાવવાની ક્ષમતામાં અલગ પડે છે, તેથી વિચારપૂર્વક પસંદ કરો. નીચેના વિભાગોમાં પ્રવેશ શું કરે છે, તે ક્યાં પહોંચાડવો પડે છે, રોટેશન ક્યારે વધુ સારો જવાબ છે અને બંનેમાંથી એક કામ કર્યું તે કેવી રીતે સાબિત કરવું તે આવરી લેવામાં આવ્યું છે.

બ્લોકલિસ્ટ પ્રવેશ ખરેખર શું કરે છે

PKI રૂપરેખાંકન એ ફિંગરપ્રિન્ટની સૂચિ આપે છે જે હોસ્ટે નકારવી પડે છે, ભલે પ્રમાણપત્ર માન્ય રીતે સહી કરેલું અને સમાપ્ત ન થયેલું હોય. અમલ સ્થાનિક રીતે થાય છે, તે સૂચિ સામે જે હોસ્ટે સેવા શરૂ થાય ત્યારે લોડ કરી હતી. પ્રવેશ વિશે કંઈ પણ પ્રમાણપત્રની અંદર મુસાફરી કરતું નથી, તેથી પીઅર પોતાને દેખાડાયેલી ક્રેડન્શિયલમાંથી નિર્ણય શીખી શકતું નથી. તેથી જ લાઇટહાઉસની અહીં કોઈ ભૂમિકા નથી: લાઇટહાઉસ પીઅરને એકબીજાને શોધવામાં અને સીધો માર્ગ નિષ્ફળ જાય ત્યાં ટ્રાફિક રિલે કરવામાં મદદ કરે છે. તે શોધ અને રિલે સ્તર છે, રૂપરેખાંકન વિતરણની ચેનલ નહીં.

એક મશીનને અપડેટ કરવાથી તે મશીનના નિર્ણયો બદલાય છે અને અન્ય દરેક પીઅર બરાબર પહેલા જેવું જ રહે છે. જે પીઅર સહી કરતી સત્તા પર ભરોસો કરે છે અને પ્રવેશ કદી જોયો નથી તેને કંઈ પણ નકારવાનું કોઈ કારણ નથી. તેથી લાઇટહાઉસ જોઈને રદ કરવાનું પરીક્ષણ કંઈ સાબિત કરતું નથી, કારણ કે તમે જે ઘટક જોઈ રહ્યા છો તેને સૂચિનો અમલ કરવા કદી કહેવામાં આવ્યું નથી.

ઉપકરણને નહીં, પ્રમાણપત્રને ઓળખો

તમે નકારવા માંગો છો તે ક્રેડન્શિયલની ફિંગરપ્રિન્ટ વાપરો, કારણ કે હોસ્ટનામ, ઉપકરણ લેબલ કે વર્તમાન સરનામું આજે એક મશીનને ઓળખે છે અને આવતા મહિને બીજું કંઈક. એમાંથી કોઈ પણ શબ્દમાળા બ્લોકલિસ્ટમાં દેખાતી નથી, અને એમાંથી કોઈ પણ પુનઃસ્થાપનમાં ટકતી નથી. પ્રમાણપત્ર છાપો, ફિંગરપ્રિન્ટ વાંચો, અને ચકાસો કે તે નિવૃત્ત થતી ક્રેડન્શિયલનું છે, તેના બદલાનું નહીં. જ્યારે બદલો પહેલેથી જારી થઈ ગયો હોય ત્યારે બંને ફાઇલો વાંચવી મહત્વપૂર્ણ છે, કારણ કે જૂનું અને નવું પ્રમાણપત્ર નામ વહેંચી શકે છે અને અન્ય દરેક ક્ષેત્રમાં અલગ પડે છે.

કઈ ફિંગરપ્રિન્ટ ક્યારે બ્લોક થઈ તે નોંધો, જેથી પછીનું ઓડિટ પૂર્ણ થયેલા ફેરફારને ઇચ્છિત ફેરફારથી અલગ કરી શકે. પ્રવેશ શું કરતો નથી તે પણ નોંધો: તે સહી કરતી સત્તાને અમાન્ય કરતો નથી, અને તે સત્તાના ભવિષ્યના પ્રમાણપત્રને સ્વીકારાતું અટકાવતો નથી. હોસ્ટ પ્રમાણપત્રને બ્લોક કરવું અને સમાધાન થયેલી સત્તાને બદલવી એ અલગ કામગીરીઓ છે જેના પરિણામો પણ અલગ છે.

nebula-cert print -path /etc/nebula/host.crt
pki:
  blocklist:
    - "a1b2c3d4e5f6"

અન્ય કોઈ પણ રૂપરેખાંકનની જેમ તેનું વિતરણ કરો

સૂચિને એક ડિલિવરી મિકેનિઝમ સાથેના રૂપરેખાંકન તરીકે ગણો, એવી ફાઇલ તરીકે નહીં જેને કોઈ યાદ આવે ત્યારે સંપાદિત કરે. સંપૂર્ણ સૂચિ મોકલો, ડેલ્ટા નહીં, જેથી અગાઉનું અપડેટ ચૂકી ગયેલો હોસ્ટ ખાલી જગ્યાઓ એકઠી કરવાને બદલે એકત્રિત થાય. Nebula PKI દસ્તાવેજીકરણ બરાબર એ જ સૂચવે છે, અને તે સલાહને મેન્યુઅલ પ્રક્રિયામાં ફેરવવાને બદલે શબ્દશઃ અનુસરવા જેવી છે.

ખાતરી કરો કે ચાલુ સેવાએ સામગ્રી ફરી લોડ કરી છે, ફક્ત ડિસ્ક પરની ફાઇલ બદલાઈ છે એટલું જ નહીં. કયા મશીનોએ ફેરફાર લાગુ કર્યો તેનું ટ્રેકિંગ રાખો અને બાકીની સૂચિ ખાલી થાય ત્યાં સુધી દેખાય તેમ રાખો. એક અઠવાડિયું બંધ લેપટોપ એ પીઅર છે જેણે નિર્ણય કદી શીખ્યો નથી, અને તે એવા નેટવર્કથી ફરી જોડાઈ શકે છે જેની કોઈને અપેક્ષા ન હતી. ફિંગરપ્રિન્ટની બાજુમાં ડિલિવરી પદ્ધતિ નોંધો, કારણ કે આગલું રદ કરવું તેને ફરી વાપરે છે અને પ્રક્રિયાનું ડિબગિંગ પહેલાના સમયે જ થાય છે.

બ્લોકલિસ્ટ કે સત્તા રોટેશન

બ્લોકલિસ્ટ પ્રવેશ સાંકડો છે: એક ઓળખ કામ કરવાનું બંધ કરે છે અને બાકીનું બધું ચાલુ રહે છે. સહી કરતી સત્તાનું રોટેશન વિશાળ છે: તેણે જારી કરેલું દરેક પ્રમાણપત્ર વિશ્વાસપાત્ર રહેતું નથી, અને દરેક હોસ્ટને નવી ક્રેડન્શિયલ અને નવું વિશ્વાસ એન્કર જોઈએ. પહેલું લક્ષિત રદ કરવું છે અને બીજું સ્થળાંતર છે, તેથી તેમને અલગ મંજૂરીઓ અને અલગ જાળવણી વિન્ડો જોઈએ. કોષ્ટક બંનેને વ્યાપ, પ્રયત્ન અને ઉલટાવવાની ક્ષમતા પર સાથે મૂકે છે.

ખોવાયેલો લેપટોપ બ્લોકલિસ્ટ માંગે છે, કારણ કે નુકસાનનો વ્યાપ એક ઓળખ છે અને જો તમે ખોટી ફિંગરપ્રિન્ટ બ્લોક કરી હોય તો ફેરફાર ઉલટાવી શકાય છે. લીક થયેલી સત્તા કી રોટેશન માંગે છે, કારણ કે બ્લોકલિસ્ટ હજી જારી ન થયેલા પ્રમાણપત્રોમાં મદદ કરી શકતી નથી. એ અંતિમો વચ્ચે, પૂછો કે શું ખુલ્લી ક્રેડન્શિયલ બીજું કંઈ સહી કરી શકી હોત, કારણ કે સત્તા એક હોસ્ટથી વધુ છે.

ઘટના પહેલાં નિર્ણય લખો, કારણ કે દબાણ હેઠળ પસંદગી કરવાથી ડિફોલ્ટ રીતે વિશાળ વિકલ્પ આવે છે. તમે જે માર્ગ લો, બાકીની કામગીરી સમાન છે: જે હોસ્ટ મહત્વના છે તેમના પર અમલ થયો તે સાબિત કરો. તે ક્ષણે ફિંગરપ્રિન્ટ અને તારીખ નોંધવી તે પછી સાબિતી શક્ય બનાવે છે.

નકાર અને બાકીના ભાગની ચકાસણી કરો

બ્લોક થયેલી ઓળખથી જોડાઓ અને નિષ્ફળતાની પુષ્ટિ કરો, પછી અધિકૃત પીઅરથી જોડાઓ અને પુષ્ટિ કરો કે તે હજી પોતાને જોઈએ તે સુધી પહોંચે છે. જે ફેરફાર બધાને તોડે છે તે સફળ રદ કરવું નથી. બંને નવા સત્રોમાંથી કરો, કારણ કે કેશ થયેલી સ્થિતિ પરિણામ છુપાવી શકે છે.

ચકાસો કે ફેરફાર પછી સ્થાપિત સત્ર સમાપ્ત થાય છે કે નહીં, અને ફાઇલ સંપાદિત કરવાથી કંઈ પણ સમાપ્ત થાય છે એમ માનવાને બદલે તમારી આવૃત્તિ અને રૂપરેખાંકન માટે વર્તન નોંધો. disconnect_invalid વિકલ્પ એવા ક્લાયન્ટને આવરે છે જેમના પ્રમાણપત્ર સમાપ્ત થયેલા કે અમાન્ય છે, તેથી તેના પર આધાર રાખતા પહેલાં તે તમારા કેસ પર કેવી રીતે લાગુ પડે તેની પુષ્ટિ કરો. જો તાત્કાલિક સમાપ્તિ જરૂરી હોય, તો તેને ખાસ પરીક્ષણ કરો અને તમે શું જોયું તે નોંધો. પછી પુનઃપ્રારંભ પછી પરીક્ષણનું પુનરાવર્તન કરો, કારણ કે જે હોસ્ટ સૂચિનો અમલ માત્ર આગલા રીબૂટ સુધી જ કરે છે તેને ડિલિવરી સમસ્યા છે જે પહેલા પરીક્ષણે છુપાવી હતી. સ્વસ્થ લાઇટહાઉસ તમને કહે છે કે શોધ કામ કરે છે, એ નહીં કે કોઈ પીઅરે નીતિ લાગુ કરી છે.