વિશેષાધિકારો ઘટાડ્યા પછી: કઈ OpenVPN ફાઇલો હજી કામ કરે છે?
ઘટાડા પહેલાં ખોલાયેલા ડિસ્ક્રિપ્ટર હજી કામ કરે છે; પછી ફરી ખોલાતા માર્ગો નહીં. તમારા સેટઅપને ત્રણ રનટાઇમ ફાઇલોમાંથી કઈ ફરી ખોલવી પડશે તે નક્કી કરો.
લાંબો અપટાઇમ ફક્ત એ સાબિત કરે છે કે તે ક્ષણે ડિમન પાસે રહેલા વિશેષાધિકારો સાથે શરૂઆત સફળ થઈ. અહીં મહત્ત્વની નિષ્ફળતાઓ પછી આવે છે: નવો ક્લાયન્ટ જોડાય છે, રિવોકેશન યાદી બદલાય છે, સહાયક સ્ક્રિપ્ટને ફાઇલ લખવી પડે છે. એમાંનું દરેક વિશેષાધિકાર વગરના ખાતા દ્વારા કરાયેલું નવું ખોલવું છે, તેની પોતાની પરવાનગીની પ્રશ્ન અને પોતાનો ભૂલ સંદેશ સાથે. ત્રણ નિર્ણયો કામ ચાલુ રાખતી રૂપરેખાને આગલી ઘટનામાં નિષ્ફળ થતી રૂપરેખાથી અલગ પાડે છે.
જે વહેલું લોડ થયું તેને પછી ખૂલતા ભાગથી અલગ કરો
ડિસ્ક્રિપ્ટર એ ખુલ્લા ફાઇલ વર્ણન પરનું હેન્ડલ છે, અને પ્રવેશ મોડ તે વર્ણન બન્યું ત્યારે નિશ્ચિત થયો હતો. પછી પ્રક્રિયાનો વપરાશકર્તા બદલવાથી હેન્ડલ બંધ થતું નથી, તેથી રૂટ તરીકે વાંચેલી કી ફાઇલ ઘટાડા પછી પણ કામ કરે છે. મોડ પણ બદલાતો નથી: વાંચવા માટે ખોલેલું હેન્ડલ લખી શકાય તેવું બનતું નથી, અને લખી શકાય તેવું હેન્ડલ ફક્ત એટલા માટે રદ થતું નથી કે ખાતાએ માર્ગ પરના અધિકાર ગુમાવ્યા છે. આ બે હકીકતો આ અહેવાલોમાંનું મોટા ભાગનું આશ્ચર્યજનક વર્તન સમજાવે છે.
બીજો અડધો ભાગ સ્મૃતિ છે. ડિમન પ્રમાણપત્રનું વિશ્લેષણ કરી, વિશ્લેષિત સામગ્રી રાખી અને ફાઇલ બંધ કરી શકે છે; વપરાશમાં રહેતું તે માહિતી છે, ખુલ્લી ફાઇલ નહીં. તેથી ચાલુ ટ્રાફિક ન તો સાબિત કરે છે કે ડિસ્ક્રિપ્ટર ખુલ્લું છે ન તો કે માર્ગનું નામ પહોંચી શકાય છે. તે ફક્ત સાબિત કરે છે કે વર્તમાન સત્ર માટે જરૂરી સામગ્રી પહેલાં મળી હતી.
પછીનું ખોલવું બીજો વ્યવહાર છે. તે વર્તમાન ઓળખપત્રો, વર્તમાન સુરક્ષા સંદર્ભ અને વર્તમાન માઉન્ટ દૃશ્ય હેઠળ ચાલે છે, તેથી શરૂઆતમાં વાંચી શકાય તેવો માર્ગ આગલા જોડાણમાં નકારી શકાય છે. પરિભ્રમણ એક જાળ ઉમેરે છે: એ જ માર્ગ નામ પર નવી ફાઇલ લખવાથી અસ્તિત્વમાંનું ડિસ્ક્રિપ્ટર જૂના ઑબ્જેક્ટ સાથે જોડાયેલું રહે છે, તેથી ફરી લોડ થવું સફળ લાગે જ્યારે ડિમન હજી પહેલાનું સામગ્રી વાપરતું હોય. પરિભ્રમણ અમલમાં આવ્યું માનતા પહેલાં પ્રક્રિયા પાસેના inode ને ડિસ્ક પરના inode સાથે સરખાવો.
ત્રણ રનટાઇમ વાંચન અને દરેક ક્યારે થાય તે નામ આપો
ત્રણ સ્રોત સામાન્ય રીતે શરૂઆત પછી ઘણા સમયે ખૂલે છે, અને જુદા જુદા સમયે નિષ્ફળ જાય છે. ચોક્કસ ક્લાયન્ટની રૂપરેખા ફાઇલ તે ક્લાયન્ટ જોડાય ત્યારે વાંચાય છે, તેથી અન્ય ચાલુ રહે ત્યારે એક વપરાશકર્તા માટે તૂટી શકે છે. રિવોકેશન માહિતી પીઅર પ્રમાણીકરણ દરમિયાન અને ફાઇલ બદલાય ત્યારે ફરી જોવાય છે. કામચલાઉ ડિરેક્ટરીને ફક્ત ત્યારે સ્પર્શ થાય છે જ્યારે સ્ક્રિપ્ટ કે પ્લગઇન કંઈક લખે.
ત્રણમાંથી કોઈ પણ શરૂઆતના માર્ગનું નથી, તેથી અઠવાડિયાં સુધી સ્વસ્થ રહેલું સર્વર આગલા જોડાણમાં નિષ્ફળ જઈ શકે. વર્ગ સુધારણાના માલિકને પણ નામ આપે છે: પ્રથમ બે ડિમન ખાતા હેઠળ રૂપરેખા પર વાંચન પરવાનગી છે, અને ત્રીજું સાંકડા હેતુનું લખી શકાય તેવું સ્થાન છે.
| Path reopened later | What triggers the open | First sign when it fails |
|---|---|---|
| Client configuration file | A connection for that client identity | One client rejected while others connect |
| Revocation data | Peer authentication, including after replacement | Revoked and valid peers both refused |
| Script or plugin temporary directory | A helper needs to create a file | The helper exits with a path error |
persist-key લોકો ધારે તેના કરતાં વધુ સાંકડા પ્રશ્નનો જવાબ આપે છે. તે દસ્તાવેજીકૃત SIGUSR1 અને ping-restart રીસેટ દરમિયાન કી ફાઇલ ખુલ્લી રાખે છે, અને તે CCD ફાઇલો, રિવોકેશન માહિતી, સહાયક એક્ઝિક્યુટેબલ કે સંપૂર્ણ પ્રક્રિયા પુનઃશરૂ કરવા માટે કંઈ કરતું નથી. તે હજી પોતાના ખોલવાના માર્ગો અનુસરે છે, તે ક્ષણે ચાલતા કોઈ પણ ખાતા હેઠળ.
ખાતું અને તેની ખરેખરની દૃષ્ટિ ખાતરી કરો
યુનિટ ફાઇલ પર ભરોસો કરવાને બદલે ચાલતા ડિમનને પૂછો કે તે કયું ખાતું વાપરે છે, પછી જવાબને યુનિટ જે નક્કી કરે તેની સાથે સરખાવો. અસંગતિ પહેલી ઉકેલવાની વસ્તુ છે, કારણ કે પછીની દરેક પરવાનગી તપાસ પ્રક્રિયા ખરેખર જે છે તે તરીકે ચાલે છે. પછી માર્ગને એક એક ઘટક તરીકે ચાલો; પસાર થવું દરેક સ્તરે મૂલ્યાંકન થાય છે, તેથી પસાર ન થઈ શકાય તેવી ડિરેક્ટરીમાંની વાંચી શકાય તેવી ફાઇલ પણ અવાંચ્ય રહે છે. અંતિમ ફાઇલ મોડ પહેલો નહીં, છેલ્લો પ્રશ્ન છે.
નામસ્થળો અને સેવા સેન્ડબોક્સ માલિકી અને મોડ બિટ જે વર્ણવતા નથી તેવી સીમાઓ ઉમેરે છે. તમારા શેલમાં દેખાતો માર્ગ chroot, માઉન્ટ નામસ્થળ કે ઘરની ડિરેક્ટરીઓ છુપાવતા યુનિટની અંદર ગેરહાજર કે ફક્ત-વાંચન હોઈ શકે. સુરક્ષા મોડ્યુલ વધુ એક સ્તર ઉમેરે છે, તેથી વાંચી શકાય તેવી લાગતી ફાઇલ પણ ખૂલે ત્યારે નકારાઈ શકે છે.
ps -o user:12,pid,args -C openvpn
systemctl show -p User -p Group -p ProtectHome -p RootDirectory [email protected]
sudo -u openvpn namei -l /etc/openvpn/ccd/aliceવ્યવસ્થાપકના શેલમાં સફળ વાંચન એ સંયુક્ત શરતોમાંથી એક પણ ચકાસતું નથી. તપાસ ડિમન ખાતા સાથે, એ જ નામસ્થળ અને સેન્ડબોક્સ સાથે ચલાવો, અથવા પરિણામ સર્વરને નહીં પણ તમારા શેલનું વર્ણન કરે છે તેમ સ્વીકારો. ત્રીજો આદેશ એ પરીક્ષણનું સસ્તું સ્વરૂપ છે: તે દરેક ઘટકનો મોડ છાપે છે અને ડિમન ખાતું જેનાથી પસાર ન થઈ શકે તે પ્રથમ ઘટક પર નિષ્ફળ જાય છે.
રનટાઇમ લેખનને પોતાની ડિરેક્ટરી આપો
વાંચન યાદીનો ફક્ત અડધો ભાગ છે. સહાયક સ્ક્રિપ્ટને સ્થિતિ ફાઇલ બનાવવી પડી શકે, પ્લગઇનને તેની રૂપરેખાની બાજુમાં સ્થિતિ લખવી પડી શકે, અને એ લેખનો રૂપરેખા વૃક્ષને લખી શકાય તેવું બનાવવાથી આવરી લેવાતા નથી. ચોક્કસ ડિરેક્ટરીને તેની કાર્યક્ષમતાને જરૂરી લેખન પરવાનગી આપો, એવા માલિક અને મોડ સાથે જે તમે સમજાવી શકો. ફક્ત વંચાતી દરેક વસ્તુ માટે ફક્ત-વાંચન પ્રવેશ પસંદ કરો.
ખાનગી કીની પરવાનગીઓ નીતિ ફાઇલોથી અલગ રાખો. રીસેટ પછી ફરી વાંચવી પડે તેવી કીની જરૂરિયાત દરેક જોડાણે વંચાતી ક્લાયન્ટ ફાઇલ કરતાં જુદી છે, અને બંને માટે એક ઉદાર મોડ સમસ્યા માગે તેના કરતાં વધુ પ્રવેશ આપે છે. સાંકડી માલિકીનું સમર્પિત ડિમન ખાતું પહોળા જૂથ કરતાં તપાસવું સહેલું છે. જ્યારે કીએ રીસેટ ટકીવા પડે ત્યારે, persist-key ડિરેક્ટરી પહોળી કરવાને બદલે ફરી વાંચવું દૂર કરે છે.
તમે પુનઃઉત્પાદન કરી શકો તે ઘટનાથી નિર્ણય લો
જીવંત ટનલ કોડમાંથી એક જ માર્ગ સાબિત કરે છે. જે ઘટનાને ફાઇલની જરૂર છે તે જ તમારા માટે મહત્ત્વના ખોલવાને આવરે છે, પછી તે નવું ક્લાયન્ટ જોડાણ હોય, બદલાયેલી રિવોકેશન ફાઇલ હોય, મંજૂર નરમ રીસેટ હોય કે આયોજિત પુનઃશરૂઆત હોય. ઘટના પસંદ કરો, ચલાવો, અને છેલ્લી નહીં પહેલી ભૂલ રાખો.
નરમ રીસેટ માટે એક સિગ્નલ અને યુનિટનો લોગ બતાવે છે કે કી ફરી વંચાઈ કે નહીં. સિગ્નલ મોકલો, પછી યુનિટે લખેલી છેલ્લી લાઇનો વાંચો:
systemctl kill -s SIGUSR1 [email protected]
journalctl -u [email protected] -n 40 --no-pagerફક્ત વિશેષાધિકાર ઘટ્યા છે તેથી ચેપગ્રસ્ત ડિમન હવે ફાઇલો બદલી શકતું નથી તેવું અનુમાન ન કરો. તે હજી શું કરી શકે તે બાકીના ઓળખપત્રો, તેની ક્ષમતાઓ, તે જે ડિરેક્ટરીઓમાં લખી શકે અને હજી ધરાવતા કોઈ પણ લખી શકાય તેવા ડિસ્ક્રિપ્ટર પર આધારિત છે. વિશેષાધિકાર ઘટાડવાથી સત્તા સાંકડી થાય છે, અને રનટાઇમ ખોલવાની યાદી બતાવે છે કે કેટલી. એ સીમા રૂપરેખાની બાજુમાં લખો જેથી આગલા વ્યક્તિએ ફરી શોધવી ન પડે.