OpenVPN પ્રોફાઇલમાં ત્રણ સર્ટિફિકેટ બ્લોક છે: કયો ગુપ્ત છે?

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

એક ફાઇલ, ત્રણ બ્લોક, અલગ કામ

સામાન્ય પ્રોફાઇલ BEGIN અને END માર્કર વચ્ચે ca બ્લોક, cert બ્લોક અને key બ્લોક ઉમેરે છે, અથવા તે જ ત્રણને અલગ ફાઇલો તરીકે દર્શાવે છે. કેટલાક પ્રોફાઇલ tls-auth અથવા tls-crypt કી માટે ચોથો બ્લોક ઉમેરે છે, જે સર્ટિફિકેટ નહીં પણ વહેંચાયેલ રહસ્ય છે. ક્લાયન્ટ દરેક બ્લોક તેને નામ આપતા નિર્દેશ મુજબ વાંચે છે, તેથી લેબલ તેમના દેખાવાના ક્રમ કરતાં વધુ મહત્વપૂર્ણ છે.

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

બ્લોકની આસપાસના નિર્દેશ નક્કી કરે છે કે તે કેવી રીતે વપરાય. ca બદલો અને ક્લાયન્ટ બીજી સત્તા પર ભરોસો કરે છે; key બદલ્યા વિના cert બદલો અને હેન્ડશેક વિશ્વાસ સાથે કોઈ સંબંધ ન ધરાવતી અસંગતિથી નિષ્ફળ જાય છે.

CA બ્લોક જાહેર છે, CA કી ક્યારેય નહીં

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

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

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

સર્વર અને ક્લાયન્ટ સર્ટિફિકેટ વિરુદ્ધ દિશામાં ઇશારો કરે છે

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

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

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

બે પ્રોમ્પ્ટ જે એકસરખા લાગે છે અને છે નહીં

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

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

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

સ્વચ્છ હેન્ડશેક શું સાબિત કરે છે અને શું નહીં

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

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