ફક્ત પાસવર્ડવાળી OpenVPN પ્રોફાઇલમાં કઈ CA ફાઇલ જાય છે?

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

ક્રમ મહત્ત્વનો છે: છેલ્લા બે પ્રશ્નોનો અર્થ ત્યારે જ થાય છે જ્યારે તમે જાણો કે કયું મટીરિયલ હોવું જોઈએ.

પ્રોફાઇલ પહેલેથી શું ધરાવે છે તેનાથી શરૂ કરો

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

ca /absolute/path/operator-ca.crt
auth-user-pass
remote-cert-tls server

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

ચાર પ્રકારના મટીરિયલ અલગ કરો

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

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

ક્લાયન્ટને વિશ્વાસ ફાઇલ તરફ દોરો

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

<ca>
-----BEGIN CERTIFICATE-----
...operator-provided public CA...
-----END CERTIFICATE-----
</ca>

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

એ જ ભૂલ નહીં, આગળની ભૂલ વાંચો

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

જે ક્લાયન્ટ જોડાય છે પણ ક્યાંય પહોંચતો નથી તે વિશ્વાસ સંપૂર્ણ પાર કરી ગયો છે અને હવે રૂટિંગ કે DNS પ્રશ્નનો સામનો કરે છે.

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