OpenVPN auth-user-pass: ફાઇલ, stdin કે પ્રોમ્પ્ટ? કેવી રીતે પસંદ કરવું

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

તેને નક્કી કરતી ત્રણ શરતો

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

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

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

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

દરેક ઇનપુટ માર્ગ ખરેખર શું કરે છે

--auth-user-pass એકલું કન્સોલ પર વપરાશકર્તાનામ અને પાસવર્ડ માંગે છે. ફાઇલનું નામ આપો તો ક્લાયન્ટ પ્રથમ લીટીને વપરાશકર્તાનામ અને બીજી લીટીને પાસવર્ડ તરીકે લે છે; કોઈ પણ અવતરણ, ટિપ્પણી કે કી-વેલ્યુ સિન્ટેક્સને ટેકો આપતું નથી. આખું ફોર્મેટ આ જ છે, તેથી જે કોઈ INI ફાઇલની અપેક્ષા રાખીને તેને સંપાદિત કરે તે તેને તોડે છે. ઇનલાઇન <auth-user-pass> બ્લોક પ્રોફાઇલની અંદર એ જ બે લીટીઓ રાખે છે, જે પ્રોફાઇલને પોતે રહસ્ય બનાવે છે અને તેને ખાનગી કી જેવા જ હેન્ડલિંગ વર્ગમાં મૂકે છે.

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

ફાઇલ બરાબર બે લીટીની હોવી જોઈએ

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

install -m 600 /dev/null /etc/openvpn/client.creds
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client.creds
od -c /etc/openvpn/client.creds | head -3

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

સર્વરને દોષ આપતા પહેલાં ફાઇલનું પરીક્ષણ કરો. openvpn --config client.ovpn --auth-user-pass /etc/openvpn/client.creds --verb 4 ચલાવવાથી છપાય છે કે ફાઇલ ખૂલી હતી કે નહીં અને પછીથી ઓળખપત્રો સ્વીકારાયા હતા કે નહીં, જે તમને કહે છે કે આગળ કયો સ્તર બદલવો છે.

પ્રવાહ, stdin અને તેમાંથી ઉત્પન્ન થતી ભૂલો

પાસવર્ડને પાઇપમાં નાખવો એ મોટાભાગના લોકો પહેલાં પ્રયત્ન કરે છે અને સૌથી વધુ આશ્ચર્ય ધરાવતો માર્ગ છે. પ્રક્રિયા અવેજીકરણ કામ કરે છે કારણ કે ક્લાયન્ટને ફક્ત વાંચી શકાય તેવા ડિસ્ક્રિપ્ટરની જરૂર છે: openvpn --config client.ovpn --verb 3 --auth-user-pass <(printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS"). /dev/stdin પસાર કરવું ફક્ત ત્યારે કામ કરે છે જ્યારે ક્લાયન્ટ પૂછે તે ક્ષણે stdin હજી ખુલ્લું અને વાંચી શકાય તેવું હોય, જે પહેલેથી તેને વાપરી નાખેલી પાઇપલાઇનમાં સાચું નથી.

ERROR: could not read Auth username from stdin ના બે અલગ કારણો છે. કેટલાક 2.3.x ક્લાયન્ટ પર સંદેશ stdin હેન્ડલિંગની ખામીથી આવ્યો હતો જે પછીના 2.3 પ્રકાશનોએ સુધારી હતી, તેથી એટલો જૂનો ક્લાયન્ટ ફક્ત અપગ્રેડ દ્વારા સુધરે છે. વર્તમાન ક્લાયન્ટ પર એ જ શબ્દરચનાનો અર્થ છે કે ક્લાયન્ટે કન્સોલ ઇનપુટ માંગ્યું અને stdin ટર્મિનલ ન હતું - બરાબર એ જ સ્થિતિ systemd એકમ, cron કાર્ય, અથવા -t વિના શરૂ કરેલા કન્ટેનરમાં.

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

જ્યારે બીજી પ્રક્રિયા પ્રોમ્પ્ટની માલિક હોય ત્યારે વ્યવસ્થાપન ઇન્ટરફેસ

જે નિયંત્રક પહેલેથી ટનલની દેખરેખ રાખે છે તે તેના પ્રશ્નોના જવાબ પણ આપી શકે છે. ક્લાયન્ટને --management 127.0.0.1 7505 સાથે શરૂ કરો, સ્થિતિની લીટીઓ વાંચો, અને >PASSWORD:Need 'Auth' username/password પર ધ્યાન રાખો. નિયંત્રક અલગ કમાન્ડ લીટીઓ પર username "Auth" alice અને પછી password "Auth" ... સાથે જવાબ આપે છે. 'Auth' ટોકન વિનંતીમાંથી ઓળખકર્તાનું પુનરાવર્તન કરે છે અને તે મેળ ખાવો જોઈએ, અન્યથા જવાબ અવગણવામાં આવે છે અને ક્લાયન્ટ રાહ જુએ છે.

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

ઓળખપત્ર સમસ્યા જેવી લાગતી નિષ્ફળતાઓ

ક્યારેય પૂર્ણ ન થતી TLS હેન્ડશેક, અથવા VERIFY ERROR: depth=0, error=certificate signature failure, વિશ્વાસની સમસ્યા છે અને કોઈ વપરાશકર્તાનામ વાંચવામાં આવે તે પહેલાં થાય છે. UDP શ્રોતા તરફ નિર્દેશિત proto tcp ક્લાયન્ટ તે જ જગ્યાએ નિષ્ફળ જાય છે: પેકેટ ક્યારેય પ્રમાણીકરણ તબક્કે પહોંચતા નથી, તેથી દરેક પાસવર્ડ સંગતતાને કારણે ખોટો લાગે છે. ઓળખપત્ર મોકલાય તે પહેલાં પ્રમાણપત્ર ચકાસણી ચાલુ રાખો; પરિચિત પ્રોમ્પ્ટ પાસવર્ડ કોણ મેળવે છે તે વિશે કંઈ કહેતું નથી. ઓળખપત્રને સ્પર્શતા પહેલાં પ્રમાણપત્ર સાંકળ, સામાન્ય નામ અને પરિવહન તપાસો.

પ્રોફાઇલ એસેમ્બલ કરતી સ્ક્રિપ્ટમાં shell ભૂલો બીજો ખોટો સુરાગ છે. [ ! -f "$file" ] ની અંદર ખૂટતી જગ્યા command not found ઉત્પન્ન કરે છે, સ્ક્રિપ્ટ વહેલી અટકે છે, પ્રોફાઇલ ક્યારેય ફરી બંધાતું નથી, અને ક્લાયન્ટ પાછલા સાથે શરૂ થાય છે. તે ભૂલ shellની છે, પ્રમાણીકરણની નહીં, અને પાસવર્ડ ફરી ટાઇપ કરવાથી તે ભૂંસાશે નહીં.

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

• પ્રથમ પ્રોટોકોલ ભૂલ વાંચો, છેલ્લી ઓળખપત્ર લીટી નહીં: TLS, પછી પ્રમાણીકરણ, પછી push.
• ખાતરી કરો કે ફાઇલ બે લીટીની છે, તેમાં કેરેજ રિટર્ન નથી, અને તે સંપૂર્ણ માર્ગ દ્વારા સંદર્ભિત છે.
• ખાતરી કરો કે પ્રોફાઇલ અને કમાન્ડ લાઇન નિર્દેશ અંગે અસહમત નથી.
• "ઓળખપત્રો સ્વીકારાયા" ને "ટ્રાફિક વહે છે" થી અલગ કરો - રૂટિંગ અને DNS પછીનું સ્તર છે.

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