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

મિકેનિઝમ પસંદ કરતાં પહેલાં પ્રોમ્પ્ટને નામ આપો

ચાર પ્રોમ્પ્ટ ટર્મિનલ પર સરખા દેખાય છે. એકાઉન્ટ જોડી સર્વરની PAM અથવા auth-user-pass-verify ગોઠવણીમાંથી આવે છે અને auth-user-pass તેનો જવાબ આપે છે. ખાનગી કીનો પાસફ્રેઝ કી ફાઇલનો છે અને --askpass દ્વારા વાંચવામાં આવે છે અથવા હાથે ટાઇપ કરવામાં આવે છે. PKCS#12 બંડલ પોતાનો પાસવર્ડ માંગે છે. પ્રોક્સી પ્રમાણીકરણ એકાઉન્ટ ક્રેડેન્શિયલ નહીં, --http-proxy જે auth ફાઇલ લે છે તે વાપરે છે.

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

auth-user-pass: એક ફાઇલ, એક પ્રોમ્પ્ટ

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

બે વિગતો સાચી ફાઇલને પ્રોમ્પ્ટમાં ફેરવે છે. CRLF સાચવતો એડિટર પાસવર્ડ સાથે ચોંટેલું કેરેજ રિટર્ન છોડે છે, તેથી સર્વર એવો પાસવર્ડ નકારે છે જે ફાઇલમાં સાચો લાગે છે; આંખથી નહીં, cat -A કે od -c સાથે ચકાસો. અને પ્રોફાઇલની અંદર આર્ગ્યુમેન્ટ વગરનું auth-user-pass ડિઝાઇન મુજબ «વપરાશકર્તાને પૂછો» એમ કહે છે, જેને કમાન્ડ લાઇન પરનું બીજું નિર્દેશન કદાચ ઓવરરાઇડ કરી શકે નહીં, કારણ કે પ્રોફાઇલ જ્યાં છે ત્યાં જ પાર્સ થાય છે.

વિકલ્પોનો ક્રમ ત્રીજો જાળ છે, અને તે આવૃત્તિ-આધારિત છે. કેટલાક OpenVPN 2.4 બિલ્ડ --config પહેલાં આવે ત્યારે --auth-user-passને અવગણે છે, તેથી એ જ બે વિકલ્પો બીજા ક્રમમાં કનેક્ટ થાય છે. નિર્દેશન પ્રોફાઇલની અંદર અથવા કમાન્ડ લાઇન પર --config પછી મૂકો, અને બીજું કંઈ બદલતાં પહેલાં પ્રોફાઇલમાં દરેક ઘટનાને grep કરો.

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

મેનેજમેન્ટ સોકેટ: દરેક પ્રોમ્પ્ટ, વધુ સપાટી

ક્લાયન્ટને લિસનર સાથે શરૂ કરો અને સ્પષ્ટ કહો કે પ્રોમ્પ્ટ તેના પર રિપોર્ટ થશે, OpenVPN 2.6 મેન્યુઅલ માં દસ્તાવેજીકૃત નિર્દેશનો વાપરીને:

management 127.0.0.1 3030
management-query-passwords

bashથી કનેક્શનને વધારાના ફાઇલ ડિસ્ક્રિપ્ટર પર રાખો અને સ્થાનને બદલે પ્રોમ્પ્ટના નામથી જવાબ આપો, કારણ કે ફરી કનેક્ટ થવું બીજા ક્રમમાં પૂછી શકે છે:

exec 3<>/dev/tcp/127.0.0.1/3030
while read -r -u 3 line; do
  case "$line" in
    *"Need 'Auth' username/password"*)
      echo 'username "Auth" alice' >&3
      echo 'password "Auth" secret' >&3 ;;
    *"Need 'Private Key' password"*)
      echo 'password "Private Key" secret' >&3 ;;
  esac
done

સીમા પરિવહન છે. મેનેજમેન્ટ પ્રોટોકોલ loopback પર TCP પર સાદો ટેક્સ્ટ છે, તેથી દૂરસ્થ નિયંત્રક સુધી પહોંચવા માટે લિસનરને LAN કે ટનલ સરનામા પર પ્રકાશિત કરવું ન જોઈએ; દૂરસ્થ નિયંત્રક એટલે SSH ફોરવર્ડ, વિશાળ બાઇન્ડ નહીં. કમ્યુનિટી ડીમન પણ એક સમયે એક જ મેનેજમેન્ટ ક્લાયન્ટ સ્વીકારે છે, તેથી GUI કે મોનિટર તમારી સ્ક્રિપ્ટ સાથે સોકેટ શેર કરી શકતું નથી. બીજું કનેક્શન કતારમાં નહીં પણ નકારવામાં આવે છે, અને નિષ્ફળતા બહેરી થઈ ગયેલી સ્ક્રિપ્ટ જેવી લાગે છે.

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

ડિપ્લોયમેન્ટમાં કઈ ફાવે છે

ક્રેડેન્શિયલ ફાઇલ પસંદ કરો જ્યારે એકમાત્ર પ્રોમ્પ્ટ એકાઉન્ટ જોડી હોય, ક્લાયન્ટ સ્થિર માલિક સાથે સેવા તરીકે ચાલે, અને તમે 600 ફાઇલ એવા બેકઅપની બહાર રાખી શકો જે તમે નિયંત્રિત કરતા નથી. મેનેજમેન્ટ સોકેટ પસંદ કરો જ્યારે કી પાસફ્રેઝ કે PKCS#12 પાસવર્ડ સંડોવાયેલો હોય, જ્યારે રેપર પહેલેથી પ્રક્રિયા પર દેખરેખ રાખતું હોય, અથવા જ્યારે ફરી કનેક્શન ડિબગ કરતી વખતે સ્ટેટસ અને પ્રોમ્પ્ટ જોવા પડે.

બે શરતો નિર્ણય ખસેડે છે. જો રેપર /bin/sh હોય, બાઇનરીને સીધું બોલાવતું systemd યુનિટ હોય, અથવા ન્યૂનતમ કન્ટેનર હોય, તો ફક્ત-bash સોકેટ ગુંદર ઉપલબ્ધ નથી અને ફાઇલ સસ્તો જવાબ છે. જો ગુપ્ત વસ્તુ વારંવાર ફરે છે, તો કોઈપણ ફાઇલ તેના માટે સારું ઘર નથી: નાના રેપરથી કીરિંગ પૂછો અને યુનિટને રેપર બોલાવવા દો, જે રોટેશનને એક જગ્યાએ રાખે છે અને પાસવર્ડને શેલ ઇતિહાસની બહાર.

પ્રોસેસ સબસ્ટિટ્યુશન બંને વચ્ચે ઊભું છે અને કોઈનું નથી. નીચેની એક લાઇન કામ કરે છે કારણ કે bash openvpn શરૂ થાય તે પહેલાં તેને વિસ્તારે છે, ક્લાયન્ટ સિન્ટેક્સ સમજે છે એટલે નહીં:

openvpn --config client.ovpn --auth-user-pass <(printf "%s
%s
" "$USER" "$PASS")

તે /bin/sh હેઠળ, શેલને બાયપાસ કરતા યુનિટમાં, અને bash કે /dev/fd વગરની ઇમેજમાં તૂટે છે. તેને ઇન્ટરેક્ટિવ પરીક્ષણ માટે રાખો, ક્યારેય એ કરાર તરીકે નહીં જેના પર સેવા આધાર રાખે છે.

ગુપ્ત વસ્તુનું રક્ષણ કરો, પછી લોગમાંથી ચકાસો

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

સાચી રન પ્રોમ્પ્ટ ક્રમ પૂર્ણ થવો અને સેશન «Initialization Sequence Completed» સુધી પહોંચવું દર્શાવે છે. જો ક્લાયન્ટ એ જ પ્રોમ્પ્ટ પર અટકે તો મેળ નિષ્ફળ ગયો: સોકેટે મોકલેલી ચોક્કસ લાઇન પ્રિન્ટ કરો, અવતરણ અને પ્રોમ્પ્ટનું નામ ચકાસો, અને sleep ઉમેરવાને બદલે પેટર્ન સુધારો. જે ટનલ સફળતા જણાવે છે અને કંઈ વહન કરતી નથી તે રૂટિંગ કે push સમસ્યા છે, ક્રેડેન્શિયલ સમસ્યા નહીં.

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

સંબંધિત લેખો