OpenVPN પ્રમાણપત્ર અને કી કેવી રીતે ઉકેલે છે: ઇનલાઇન PEM કે ફાઇલ પાથ

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

બે સંગ્રહ સ્વરૂપ, એક સૂચના

cert, key અને ca સૂચનાઓ દરેક એક પાથ અથવા ઇનલાઇન બ્લોક સ્વીકારે છે. જ્યારે કિંમત પાથ હોય, OpenVPN તે ફાઇલ ખોલે છે અને ડિસ્કમાંથી ઑબ્જેક્ટ વાંચે છે. જ્યારે રૂપરેખામાં cert ટૅગ્સથી બંધાયેલ બ્લોક હોય, ત્યારે એ જ સૂચના તેના બદલે તે ટૅગ્સ વચ્ચેનું સામગ્રી વાપરે છે, અને અલગ કોઈ ફાઇલ સંડોવાયેલી હોતી નથી.

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

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

ઇનલાઇન બ્લોક કેવી રીતે ઑબ્જેક્ટ બને છે

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

<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>

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

લોડ થયેલ પ્રોફાઇલ ખરેખર કયું સ્વરૂપ વાપરે છે તે તપાસો, તમારા એડિટરે આકસ્મિક રીતે કઈ ફાઇલ ખોલી તે નહીં:

grep -nE '^(ca|cert|key) |^<(ca|cert|key)>' client.ovpn

પાથ સંદર્ભ કેવી રીતે ઉકેલાય છે

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

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

અલગથી સંગ્રહિત પ્રમાણપત્ર માટે, તેની ઉપર કંઈ પણ ડિબગ કરતા પહેલાં ઑફલાઇન પાર્સ ઑબ્જેક્ટની પુષ્ટિ કરે છે:

openssl x509 -in client.crt -noout -subject -issuer -dates
openssl pkey -in client.key -noout -check

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

પાર્સર ભૂલ તમને શું કહી શકે છે અને શું નહીં

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

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

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