શેર થયેલ CA, અલગ દરવાજા: પ્રવેશ ફાઇલ દીઠ એક સેવા

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

વિશ્વસનીય શૃંખલા સેવા સભ્યપદ વિશે કંઈ કહેતી નથી

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

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

વૈકલ્પિક ઓવરરાઇડને પ્રવેશ દ્વારમાં ફેરવો

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

client-config-dir /etc/openvpn/service-a/clients
ccd-exclusive

સામુદાયિક આવૃત્તિ OpenVPN 2.6 ccd-exclusive તેના મેન્યુઅલ પૃષ્ઠમાં બરાબર આ શરત તરીકે દસ્તાવેજ કરે છે, અને નામવાળી ફાઇલની શોધ અસરકારક ક્લાયન્ટ ઓળખ પર આધારિત છે. અન્ય બિલ્ડ અને ઉત્પાદન-સંચાલિત સર્વર અલગ હોઈ શકે છે, તેથી બીજે ક્યાંય સમાન અર્થશાસ્ત્ર પર આધાર રાખતા પહેલાં સ્થાપિત આવૃત્તિ ખાતરી કરો.

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

દરેક સેવા માટે એક ડિરેક્ટરી, એક શેર થયેલ યાદી નહીં

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

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

અસરકારક ઓળખ નક્કી કરે છે કઈ ફાઇલ વંચાય છે

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

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

ઇનકાર, પ્રવેશ અને રદ જુદા જુદા નિરીક્ષણ કરો

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

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

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