ક્લાયન્ટ સર્ટિફિકેટ વિના OpenVPN: સર્વર નીતિ, પ્રોફાઇલ નહીં

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

પ્રોફાઇલ એ નીતિ નથી

Community OpenVPN 2.6 ફરજિયાત ક્લાયન્ટ સર્ટિફિકેટ સાથે આવે છે, કારણ કે verify-client-cert ડિફોલ્ટ રૂપે require છે. તેને none પર સેટ કરવું એ સર્ટિફિકેટની માંગ બંધ કરે છે અને ક્લાયન્ટ પ્રમાણીકરણને સર્વર પહેલેથી ચલાવતી જે તે વપરાશકર્તાનામ અને પાસવર્ડ ગોઠવણને સોંપે છે. જૂની માર્ગદર્શિકાઓ client-cert-not-required તરફ જાય છે, જે એ જ વિચારની જૂની જોડણી છે, તેથી તમારા સ્થાપિત સંસ્કરણમાં દસ્તાવેજીકૃત હોય તે નિર્દેશ વાપરો. કોઈ પણ રીતે ફેરફાર સર્વર પર થાય છે, અને કોઈ ક્લાયન્ટ પ્રોફાઇલ તેને કરી શકતું નથી.

નીચેનો ટુકડો સર્વર બાજુનો સંપૂર્ણ ફેરફાર છે, અને એકલો તે કાર્યક્ષમ પ્રમાણીકરણ રૂપરેખાંકન નથી. verify-client-cert none સર્ટિફિકેટની માંગ દૂર કરે છે, જ્યારે username-as-common-name એકાઉન્ટના નામને એ ઓળખ બનાવે છે જે પછીના કૉલબૅક્સ અને પ્રતિ-ક્લાયન્ટ ફાઇલો જુએ છે. બંનેમાંથી કોઈ લીટી પાસવર્ડ તપાસતી નથી, તેથી ચકાસક હજી પણ હોવો જોઈએ.

verify-client-cert none
username-as-common-name

એ ચકાસક એક પ્લગઇન અથવા auth-user-pass-verify દ્વારા ચાલતી સ્ક્રિપ્ટ છે, અને ઉપરની કોઈપણ લીટીનો અર્થ થાય તે પહેલાં તેને તેની જગ્યાએ હોવું જોઈએ. ક્રમ ઉલટાવવાથી તમને એવી વિંડો મળે છે જેમાં સર્વર કોઈ સર્ટિફિકેટ માંગતું નથી અને કોઈ એકાઉન્ટ તપાસતું નથી.

સર્વરને હજી શું ચકાસે છે

ક્લાયન્ટ સર્ટિફિકેટ છોડવાથી TLS છોડવાનું થતું નથી. સર્વર તેનું સર્ટિફિકેટ અને કી રાખે છે, અને ક્લાયન્ટ CA વિશ્વાસ અને હોસ્ટનામ તપાસ રાખે છે જે તેને છેતરનાર સાથે વાત કરતું અટકાવે છે. ક્લાયન્ટ પાસે હવે સર્ટિફિકેટ નથી તેથી remote-cert-tls server અથવા CA બંડલ દૂર કરવું એ સામાન્ય અને ગંભીર ખોટું વાંચન છે, અને 2.6 સંદર્ભ સ્પષ્ટ છે કે બંને દિશાઓ સ્વતંત્ર છે. એક સર્વરને ક્લાયન્ટ સમક્ષ સાબિત કરે છે; બીજું ક્લાયન્ટને સર્વર સમક્ષ સાબિત કરે છે.

પ્રોફાઇલ tls-auth અથવા tls-crypt બ્લોક પણ ધરાવી શકે છે. તે પોતાના વિતરણ અને પરિભ્રમણ ચક્ર સાથેની વહેંચાયેલ નિયંત્રણ-ચેનલ કી છે, તેથી સર્ટિફિકેટ કે કી લીટીઓ વિનાની ફાઇલ આપોઆપ પ્રકાશિત કરવા માટે સુરક્ષિત નથી. તમે તેને વાંચી ન લો ત્યાં સુધી તેને ગુપ્ત તરીકે ગણો.

કાર્યક્ષમ પ્રોફાઇલમાંથી કૉપી કરેલ સર્ટિફિકેટ ફાઇલ એકલી કંઈ સાબિત કરતી નથી; કબજો એટલે તેની સાથે મેળ ખાતી ખાનગી કી રાખવી, જે સર્ટિફિકેટ-પ્રમાણીકૃત જમાવટ તપાસે છે. સર્ટિફિકેટ ધરાવતી ફાઇલ એ ફાઇલ નથી જેનાથી પ્રમાણીકરણ કરી શકાય.

ચકાસકે શું કરવું જોઈએ

સર્ટિફિકેટની માંગ દૂર થયા પછી બધું ચકાસક પર ટકે છે: પ્લગઇન, અથવા auth-user-pass-verify દ્વારા ચાલતી સ્ક્રિપ્ટ. તેણે અમાન્ય ઓળખપત્રો નકારવા જોઈએ, નિષ્ક્રિય કે અયોગ્ય એકાઉન્ટ નકારવા જોઈએ, અને જ્યારે તે તેના બેકએન્ડ સુધી પહોંચી શકે નહીં ત્યારે બંધ રીતે નિષ્ફળ જવું જોઈએ. username-as-common-name ઘણી વાર સાથે સક્ષમ થાય છે, અને તે એ ઓળખ બદલે છે જે પછીના કૉલબૅક્સ અને પ્રતિ-ક્લાયન્ટ રૂપરેખાંકન ફાઇલો જુએ છે. તે પાસવર્ડ ચકાસતું નથી, અને અયોગ્ય એકાઉન્ટને યોગ્ય બનાવતું નથી. એ અલગ કામો છે, અને તેમને ભેગા કરવાથી જ સ્થળાંતર તેની સુખદ-માર્ગ કસોટી પાસ કરે છે અને તેની પહેલી વાસ્તવિક ઘટનામાં નિષ્ફળ જાય છે.

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

નીતિ, પ્રોફાઇલ અને મેપિંગ એકસાથે બદલો

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

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

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