અમાન્ય સિક્રેટ એ કન્ટેનરની સમસ્યા છે, પાસવર્ડ નિયમની નહીં
નકારાયેલ ક્રેડેન્શિયલ કદાચ ગેટવે સુધી પહોંચ્યું જ નહીં હોય. પહેલાં ઇનપુટ કન્ટેનર, પ્રમાણીકરણનું તબક્કો અને ખાતું જાતે સરખાવો.
«અમાન્ય સિક્રેટ» જોવાથી સામાન્ય રીતે એક નિષ્કર્ષ નીકળે છે: VPN ને વિરામચિહ્નો ગમતા નથી. એ નિષ્કર્ષ સામાન્ય રીતે ખોટો હોય છે, કારણ કે સંદેશ ઘણી વાર સ્થાનિક પ્રક્રિયામાંથી આવે છે, કોઈ ગેટવેએ ખાતું જોયું તે પહેલાં. બે રચનાઓ એક જ પાસવર્ડ પહોંચાડે છે, એક ગ્રાફિકલ ફીલ્ડ અને એક ક્રેડેન્શિયલ ફાઇલ, અને તે અલગ જગ્યાએ નિષ્ફળ જાય છે. જે પાસવર્ડ શરૂઆતથી જ યોગ્ય હતો તેને સરળ બનાવતા પહેલાં કન્ટેનર સરખાવો.
ભૂલ ગેટવે પહેલાં જ આવે છે
સ્થાનિક ચકાસણી, તાળું મારેલું સિક્રેટ સ્ટોર, ગેરહાજર એજન્ટ અને ખોટી રચનાવાળી ક્રેડેન્શિયલ ફાઇલ, બધા એવી નિષ્ફળતા આપે છે જેને વપરાશકર્તા એક જ નકાર તરીકે અનુભવે છે. તેમાંથી કોઈ પ્રમાણીકરણ સર્વર સાથે સંબંધિત નથી. ગેટવેનો પોતાનો નકાર અલગ ઘટના છે, અને તે સામાન્ય રીતે અલગ સંદેશ અને અલગ સમય સાથે આવે છે. તે ટનલ અસ્તિત્વમાં આવ્યા પછી અને ક્રેડેન્શિયલ મોકલાયા પછી થાય છે.
એટલે પહેલો પ્રશ્ન એ નથી કે કયા અક્ષરો માન્ય છે, પણ એ કે પ્રયાસ ક્યાં અટક્યો. જે ક્લાયન્ટે ક્યારેય કનેક્શન ખોલ્યું નથી તેને કોઈએ નકાર્યો નથી. તમે જે તબક્કો જોયો તે લખો, કારણ કે દરેક આગળનું પગલું આ વર્ગીકરણ પર આધાર રાખે છે.
આ ભેદ એ પણ બદલે છે કે કોણ સુધારશે. કન્ટેનરની સમસ્યા ઉપકરણ અને તેના માલિકની છે, જ્યારે ખાતાનો નકાર પ્રમાણીકરણ બેકએન્ડ ચલાવનારનો છે.
અક્ષરો નહીં, કન્ટેનર સરખાવો
ગ્રાફિકલ પાસવર્ડ ફીલ્ડ, કીલાની એન્ટ્રી, બે લીટીની ક્રેડેન્શિયલ ફાઇલ અને ઓટોમેશન સિક્રેટ, દરેક એક જ મૂલ્ય અલગ પરબિડીયામાં વહન કરે છે. પરબિડીયાના પોતાના નિયમો છે, અને સામાન્ય રીતે એ જ નિયમો તૂટે છે. મૂલ્ય ભાગ્યે જ સમસ્યા હોય છે; મૂલ્યનું પરિવહન સમસ્યા છે. બે વિચારો અલગ રાખો અને નિદાન ટૂંકું થશે.
| Where the value stops | What you see | What you check | Who owns the fix |
|---|---|---|---|
| GUI field or managed profile | A validation message before any connection opens | The selected authentication mode and whether the field holds the secret or the username | The device owner or the profile author |
| Keychain or secret agent | A prompt that keeps reappearing, or an agent error | Whether the agent is unlocked and holds an entry for this profile | The user who owns the keychain |
| Two-line credential file | A prompt for a password that was already supplied | Line count, line order and whether a trailing newline is present | Whoever generated the file |
| Shell argument or environment | Works interactively but fails in automation | Whether the shell expanded, trimmed or logged the value | Whoever wrote the automation |
OpenVPN 2.6 સમુદાયના ક્લાયન્ટ વિકલ્પો એ બે લીટીની ફાઇલનું auth-user-pass માટે વર્ણન કરે છે, જેમાં પાસવર્ડની લીટી ગેરહાજર હોય ત્યારનું વર્તન પણ સામેલ છે: ત્યારે ક્લાયન્ટ પોતે પૂછે છે. આ એક જ વિગત «જે પાસવર્ડ મેં પહેલેથી આપ્યો છે તે ફરી માંગે છે» જેવા અહેવાલોનો આખો વર્ગ સમજાવે છે. તે તમને એ પણ કહે છે કે ખાલી બીજી લીટી અર્થપૂર્ણ સ્થિતિ છે, નિરુપદ્રવી ફોર્મેટિંગ પસંદગી નહીં.
અવતરણ એ ફરી અલગ સ્તર છે: સામાન્ય ક્રેડેન્શિયલ ફાઇલની અંદરના અવતરણ ચિહ્નો ડેટા તરીકે સંગ્રહાય છે, જ્યારે શેલ પ્રોગ્રામ કંઈ જોય તે પહેલાં તેમને દૂર કરે છે. એક જ અક્ષર એક જગ્યાએ નિરુપદ્રવી અને બીજી જગ્યાએ રચનાત્મક છે. કોષ્ટક તમને કહી શકતું નથી કે તમારા ક્લાયન્ટે કયું કન્ટેનર વાપર્યું, તેથી પંક્તિ પસંદ કરતા પહેલાં ક્લાયન્ટનું પોતાનું રૂપરેખાંકન વાંચો.
લીટી વિરામ પણ રચનાત્મક છે. લીટીથી અલગ કરેલા ફીલ્ડવાળી ફાઇલ નવી લીટી ધરાવતું મૂલ્ય વહન કરી શકતી નથી, અને તે ફોર્મેટની મર્યાદા છે, પાસવર્ડની મજબૂતાઈ વિશેનો ચુકાદો નહીં. સિક્રેટને ટૂંકું કરીને તદ્દન બનાવેલી ફાઇલમાં ફિટ કરવાને બદલે ડિપ્લોયમેન્ટ સમર્થિત ડિલિવરી પદ્ધતિ વાપરો.
શેલના નુકસાન વિના ક્રેડેન્શિયલ ફાઇલ બનાવો
સૌથી સલામત સ્થાનિક માર્ગ સિક્રેટને શેલ ઇતિહાસ અને પ્રક્રિયાની આર્ગ્યુમેન્ટ યાદીની બહાર રાખે છે. બંને ફીલ્ડ ઇન્ટરેક્ટિવ રીતે વાંચો, પછી ક્લાયન્ટ જે બે લીટી ધારે છે તે લખો. બાકીનું બધું સરળતાથી સમીક્ષા કરી શકાય તેવી રૂપરેખાંકન ફાઇલમાં રહી શકે છે.
read -r VPN_USER
read -rs VPN_PASS
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client/creds
chmod 600 /etc/openvpn/client/creds
openvpn --config /etc/openvpn/client/office.conf --auth-user-pass /etc/openvpn/client/credsપહેલી બે આદેશો વપરાશકર્તાનામ અને પછી પાસવર્ડ દર્શાવ્યા વિના વાંચે છે, ત્રીજો બંને લીટી લખે છે, ચોથો ફાઇલને મર્યાદિત કરે છે, અને છેલ્લો તે ફાઇલ સાથે ક્લાયન્ટ શરૂ કરે છે. ધ્યાન રાખો કે read -r બેકસ્લેશ સાચવે છે, અને આ જ એવી વિગત છે જે બહાર રહી જાય તો કામ કરતા પાસવર્ડને નિષ્ફળ પાસવર્ડમાં ફેરવે છે.
અવતરણ વગરના ચલ અથવા શેલ વિસ્તરણથી ભરેલા here-document વડે ફાઇલ બનાવવાનું ટાળો. બંને ફાઇલ સુધી પહોંચતા પહેલાં અક્ષરો બદલી શકે છે, અને પરિણામી નિષ્ફળતા VPN ના નકાર જેવી લાગે છે કારણ કે ડિસ્ક પરનો પાસવર્ડ ખરેખર તમે જાણો છો તે પાસવર્ડથી અલગ છે. જો શંકા હોય તો સિક્રેટ જાતે છાપ્યા વિના ફાઇલની બાઇટ લંબાઈની અપેક્ષિત મૂલ્ય સાથે સરખામણી કરો. એક-બે બાઇટનો તફાવત અવતરણ અકસ્માતની સહી છે.
પહેલી ભૂલમાંથી તબક્કો વાંચો
એક પ્રયાસનો પહેલો ચોક્કસ સંદેશ રાખો, પછી તેનું વર્ગીકરણ કરો. સ્થાનિક ચકાસણી ભૂલ, ગેરહાજર ખાનગી કી, અનુપલબ્ધ સિક્રેટ એજન્ટ અને ગેટવે પર પ્રમાણીકરણ નિષ્ફળતા એ ચાર અલગ પરિણામો છે, ચાર અલગ માલિકો સાથે. તેમાંથી ફક્ત એક જ ખાતા વિશે છે.
જો ગેટવે ખરેખર યોગ્ય રીતે પહોંચાડાયેલા ક્રેડેન્શિયલનો નકાર કરે છે, ખાતું, પ્રમાણીકરણ બેકએન્ડ અને જરૂરી કોઈપણ ચેલેન્જ તપાસો વ્યવસ્થાપક સાથે. સામાન્ય પ્રમાણીકરણ નિષ્ફળતા કોઈ પ્રતિબંધિત અક્ષરનું નામ લેતી નથી.
મંજૂર કરેલું મૂલ્ય યોગ્ય પદ્ધતિ દ્વારા પુનઃસ્થાપિત કરો, તેને અક્ષરો અને અંકોમાં ઘટાડવાને બદલે. પાસવર્ડ નીતિ ઓપરેટરની છે, અને ચૂપચાપ તેનું ઉલ્લંઘન કરતો બાયપાસ સુધારો નથી. તે આગલી વ્યક્તિથી ખરેખરો ખામી પણ છુપાવે છે, જે નબળા પાસવર્ડ અને વધુ સારા વિચાર વિના એ જ ભૂલનો સામનો કરશે.