OpenVPN ની CA સાઇનિંગ કી /etc/openvpn ની બહાર રાખો

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

CA ના કાર્યક્ષેત્રમાં શું હોય છે

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

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

જાહેર CA પ્રમાણપત્ર જુદું છે. તે વહેંચવા માટે છે, અને ક્લાઇન્ટ અને સર્વર તેનાથી એકબીજાની ચકાસણી કરે છે.

ડિમન શરૂ થતી વખતે શું વાંચે છે

ચાલતો સર્વર થોડો સમૂહ વાપરે છે: પોતાનું પ્રમાણપત્ર, પોતાની ખાનગી કી, સાથીઓની ચકાસણી માટે CA પ્રમાણપત્ર, અને પસંદ કરેલી રીતને જે કી સામગ્રી જોઈએ તે. તે આ માર્ગો સ્ટાર્ટઅપ વખતે અને ફરી રીલોડ વખતે વાંચે છે.

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

systemctl show -p User -p Group -p ReadOnlyPaths [email protected]
stat -c '%a %U:%G' /etc/openvpn/server/server.key
runuser -u openvpn -- test -r /etc/openvpn/server/server.key; echo $?

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

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

CA કી સર્વર પર કોપી કરવાથી પછી કેમ નિષ્ફળ જાય છે

કોપી સામાન્ય રીતે ડિબગિંગના પગલા તરીકે શરૂ થાય છે: કોઈ VPN હોસ્ટ પર ક્લાઇન્ટ નવીકરણ કરવા માંગે છે, એટલે CA કી /etc/openvpn માં જાય છે અને નવીકરણ કામ કરે છે. તાત્કાલિક કામ સફળ થાય છે, અને સીમા જતી રહે છે.

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

એ સ્થિતિમાંથી પુનઃપ્રાપ્તિ ફાઇલ ડિલીટ કરવાની બાબત નથી. કી ખુલ્લી પડી હતી કે નહીં તે નક્કી કરવું પડે, પડી હોય તો CA ફેરવવો પડે, અને દરેક સાથીને ભરોસો ફરી વહેંચવો પડે. અલગ કાર્યક્ષેત્ર આખી વાતચીત ટાળે છે.

ખાતાં, ડિરેક્ટરીઓ, બેકઅપ

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

રદ કર્યા પછી સર્વર રૂપરેખાંકન જે CRL ફાઇલનું નામ આપે છે તે અપડેટ કરો, પછી સેવા રીલોડ કરો જેથી નવા કનેક્શન તેને વાંચે. Easy-RSA દસ્તાવેજીકરણ કાર્યક્ષેત્રની રચના અને સહીનો પ્રવાહ આવરી લે છે; તેની આસપાસના માલિકીના નિયમો તમારા હોસ્ટ અંગેનો નિર્ણય જ રહે છે. સેવાએ શું લોડ કર્યું તે openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate થી ખાતરી કરો, રીલોડે તે લીધું છે એમ ધારી લેવાને બદલે.

વિભાજન સાબિત કરતી કસોટી

ફક્ત કામ કરતી સ્થિતિ નહીં, નકારાત્મક સ્થિતિ પણ તપાસો. રચના મુજબ ઇશ્યુઅર ખાતેથી પ્રમાણપત્ર પર સહી કરો, પછી ખાતરી કરો કે એ જ ખાતું સેવા શરૂ કરી શકતું નથી અથવા સર્વરની ખાનગી કી વાંચી શકતું નથી. પછી ખાતરી કરો કે ડિમનનું ખાતું CA ની ખાનગી કી વાંચી શકતું નથી.

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