શું OpenConnect માં --key-password તમારો VPN એકાઉન્ટ પાસવર્ડ છે?

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

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

બે રહસ્યો, બે અલગ કામો

ભૂમિકાઓને ફાઇલ ઍક્સેસ વિરુદ્ધ નેટવર્ક પ્રવેશ તરીકે વાંચો. કી પાસવર્ડ --sslkey માં દર્શાવેલ PEM ખાનગી કીને ડિક્રિપ્ટ કરે છે જેથી TLS ક્લાયન્ટ સર્ટિફિકેટ રજૂ કરી શકાય. તે ડિક્રિપ્શન સ્થાનિક રીતે, ક્લાયન્ટ પ્રોસેસની અંદર થાય છે, અને પાસફ્રેઝ પોતે ક્યારેય ગેટવે સુધી જતું નથી. ગેટવે જે જુએ છે તે સર્ટિફિકેટ અને કી સાથે બનાવેલી સહી છે. OpenConnect નું મેન્યુઅલ --key-password ને --certificate અને --sslkey ની બાજુમાં રાખે છે, અને TPM માં રાખેલી કી વાપરી શકતા બિલ્ડમાં એ જ વિકલ્પ તેના બદલે સ્ટોરેજ રૂટ કીનો પાસવર્ડ ધરાવે છે.

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

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

કી પાસવર્ડ ખરેખર ક્યારે જરૂરી છે

વિકલ્પનો અર્થ ફક્ત ત્યારે જ છે જ્યારે ખોલવા માટે એન્ક્રિપ્ટેડ કી હોય. જો તમે વપરાશકર્તાનામ અને પાસવર્ડ સાથે અને ક્લાયન્ટ સર્ટિફિકેટ વિના કનેક્ટ થાઓ, તો --key-password પાસે કાર્ય કરવા જેવું કંઈ નથી, અને તેને ઉમેરવાથી કંઈ બદલાતું નથી. જો તમે --certificate અને --sslkey સાથે કનેક્ટ થાઓ, તો કી ફાઇલનું પોતાનું ફોર્મેટ નક્કી કરે છે કે પાસફ્રેઝ બિલકુલ માંગવામાં આવશે કે નહીં.

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

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

બંને રહસ્યોને શેલ ઇતિહાસની બહાર રાખો

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

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

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

મૃત ડેસ્કટોપ બટન એ અલગ ખામી છે

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

જ્યારે GUI કનેક્ટ થવાનો ઇનકાર કરે ત્યારે સર્ટિફિકેટ ચકાસણી ઢીલી કરવી કે ચેક બંધ કરવો લોભામણું લાગે છે. તે ક્લાયન્ટ-ઇન્ટિગ્રેશનની ખામીને સુરક્ષા ઘટાડામાં ફેરવે છે અને લૉન્ચની સમસ્યા ભાગ્યે જ ઠીક કરે છે. સર્વર ચકાસણી અકબંધ રાખો, પ્રોફાઇલ ઇચ્છિત ગેટવે તરફ છે તેની ખાતરી કરો, અને GUI જે હેલ્પરની અપેક્ષા રાખે છે તે ખરેખર ઇન્સ્ટોલ છે કે નહીં તે તપાસો.

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