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 રૂપરેખાંકન દસ્તાવેજીકરણ રીલોડ કરી શકાય તેવી સેટિંગ્સ અને અહીં વર્ણવેલી સરનામા મર્યાદા આવરી લે છે, અને ઉત્પાદન સંબંધિત કંઈપણ રોટેટ કરતા પહેલાં તેને સંપૂર્ણ વાંચવા યોગ્ય છે.