openvpn3 session-start તમારી ક્રેડેન્શિયલ ફાઇલને અવગણે છે
3.x ક્લાયન્ટ સેશન શરૂ થાય ત્યારે ક્રેડેન્શિયલ લે છે અને સાચવેલી ફાઇલ વાંચશે નહીં. પ્રોમ્પ્ટ કે ઓટોલોડ માર્ગ વાપરો, અને દરેક શું સંગ્રહે છે તે સ્વીકારો.
2.x ક્લાયન્ટ સાથે જોડાઓ અને પ્રોફાઇલ કામ કરે છે; એ જ ફાઇલ 3.x ક્લાયન્ટને આપો અને તે પાસવર્ડ પ્રોમ્પ્ટ પર અટકી જાય છે. --auth-user-pass creds.txt ને openvpn3 session-start ને આપો અને પરિણામ એ જ છે, કારણ કે નવા ક્લાયન્ટમાં ફાઇલ વાંચતો કોઈ તબક્કો નથી. ઇનકાર જાણી જોઈને છે: ક્રેડેન્શિયલ સેશનની હોય છે, અને સેશન સેવા બનાવે છે, તમારા ટર્મિનલની પ્રક્રિયા નહીં. ઇન્ટરેક્ટિવ પ્રોમ્પ્ટ અને ઓટોલોડ સહાયક વચ્ચે પસંદ કરો, અને જાણો કે દરેક શું સંગ્રહે છે.
સાચવેલી ફાઇલ પાસે જવાની જગ્યા કેમ નથી
નવા ડિઝાઇનમાં કન્ફિગરેશન મેનેજમેન્ટ અને સેશન મેનેજમેન્ટ સિસ્ટમ બસ પર વાત કરતી અલગ સેવાઓ છે. એ જ અલગતા સામાન્ય વપરાશકર્તાને સેશન શરૂ કરવા દે છે, જ્યારે વિશેષાધિકારવાળો ડીમન તેના વતી સુરક્ષિત પાસવર્ડ ફાઇલ વાંચતો નથી. ફાઇલ આધારિત ક્રેડેન્શિયલને એ મોડેલમાં સ્થાન નથી, કારણ કે ડીમન તરફથી એવી કોઈ શરૂઆત નથી જે તેમને વાંચે. ઇનકાર આર્કિટેક્ચરનું પરિણામ છે, ખૂટતી સુવિધા નહીં.
જૂની પેટર્નને નામ આપવું યોગ્ય છે જેથી ભૂલવું સહેલું થાય: પ્રોફાઇલ ક્રેડેન્શિયલ ફાઇલનો સંદર્ભ આપે છે, અને ટનલ શરૂ થાય ત્યારે ડીમન તેને વાંચે છે. નવા મોડેલમાં ક્રેડેન્શિયલ સેશનની હોય છે અને એ સેશન શરૂ થાય ત્યારે પૂરા પાડવામાં આવે છે. openvpn3 session-start --config work.ovpn તેમને પૂછે છે, અને --auth-user-pass creds.txt નકારાય છે કારણ કે એ માર્ગમાં કંઈ પણ ફાઇલ ખોલતું ન હતું. તમને મળતી દરેક 2.x રેસીપી એવા તબક્કાને ધારે છે જે હવે નથી.
કન્ફિગરેશન અને સાઇટ-સ્થાનિક સેટિંગ્સ પણ અલગ છે, જે બીજા આશ્ચર્યની સમજૂતી આપે છે. પ્રોફાઇલ પૂર્ણ લાગે છે જ્યારે તે બનાવેલા કનેક્શનમાં રૂટિંગ અને રિઝોલ્વર કન્ફિગરેશન નથી. એ ભાગો સાઇટ-સ્થાનિક સેટિંગ્સ તરીકે લાગુ થાય છે, આયાત કરેલી ફાઇલથી અલગ.
પ્રોમ્પ્ટનો માર્ગ અને તે જે સેશન છોડે છે
સેશન શરૂ થાય ત્યારે પાસવર્ડ આપવો એ ઇચ્છિત કાર્યપ્રવાહ છે. ક્લાયન્ટ એક વાર પૂછે છે, ક્રેડેન્શિયલ સેશન બેકએન્ડને સોંપે છે, અને આગળ વધે છે:
openvpn3 session-start --config work.ovpn
openvpn3 sessions-list
એ માર્ગે ડિસ્ક પર કંઈ લખાતું નથી. ટર્મિનલ બંધ થયા પછી પણ સેશન ચાલુ રહે છે, જે એવા લોકોને નવાઈ પમાડે છે જેઓ ધારે છે કે પ્રક્રિયા તેમના શેલ સાથે મરી જશે. સેશન હેન્ડલિંગને સેવામાં ખસેડવાનો હેતુ એ જ છે. સેશન તેને માંગનારા ટર્મિનલ કરતાં વધુ જીવે છે, અને તેને સ્પષ્ટ રીતે થોભાવવું પડે છે.
સામે માણસ હોય એવા વર્કસ્ટેશન માટે આ સૌથી સુરક્ષિત વિકલ્પ પણ છે, કારણ કે સાચવેલું કોઈ રહસ્ય સુરક્ષિત કરવાનું કે ભૂલવાનું નથી. જ્યાં ટાઇપ કરવા કોઈ ન હોય ત્યાં જ તે અયોગ્ય છે.
કીબોર્ડ પર માણસ વિના ઓટોમેશન
જ્યાં મશીનને માણસ વિના જોડાવું પડે છે, ત્યાં પ્રોજેક્ટ openvpn3-autoload આપે છે. તે પ્રોફાઇલનું ડિરેક્ટરી અને દરેક પ્રોફાઇલ માટે મેળ ખાતું ડિસ્ક્રિપ્ટર વાંચે છે, અને ડિસ્ક્રિપ્ટર ક્રેડેન્શિયલ સાદા ટેક્સ્ટમાં પૂરા પાડે છે. સહાયક અલગ બાઇનરી છે, સામાન્ય રીતે /usr/sbin/openvpn3-autoload પર, session-start પરનો કોઈ ફ્લેગ નહીં. તેને સેટ કરવાનો અર્થ છે ડિરેક્ટરી બનાવવી, ડિસ્ક્રિપ્ટર જે નામ ધારે છે તે નામે પ્રોફાઇલ કોપી કરવી, અને ડિસ્ક્રિપ્ટર લખવું.
પ્રતિ-વપરાશકર્તા સેટઅપ આવો દેખાય છે, અને સેશનનો માલિક બનનારા ખાતા તરીકે ચલાવાય છે. ડિરેક્ટરી મોડ બીજા સ્થાનિક વપરાશકર્તાઓને બહાર રાખે છે:
mkdir -m700 -p ~/.openvpn3/autoload
cp work.ovpn ~/.openvpn3/autoload/client.conf
$EDITOR ~/.openvpn3/autoload/client.autoload
ડિસ્ક્રિપ્ટર ક્રેડેન્શિયલનું નામ આપે છે અને સ્વયં શરૂઆત માંગે છે. પાસવર્ડની કિંમત વર્ઝન કન્ટ્રોલની બહાર રાખો:
{
"autostart": true,
"user-auth": {
"autologin": true,
"username": "svc-vpn",
"password": "change-this-value"
}
}
પછી સહાયકને એક વાર બોલાવો અને ખાતરી કરો કે સેશન દેખાય છે. બીજો આદેશ ચકાસણી છે, બીજું સેટઅપ પગલું નહીં:
/usr/sbin/openvpn3-autoload --directory ~/.openvpn3/autoload
openvpn3 sessions-list
બૂટ વખતે openvpn3-autoload.service નામનું પેકેજ કરેલું યુનિટ સિસ્ટમ-વ્યાપી ડિરેક્ટરી /etc/openvpn3/autoload વાપરે છે, પ્રતિ-વપરાશકર્તા ડિરેક્ટરી નહીં. એ સ્થાનને root માલિકી અને વધુ કડક મોડ જોઈએ છે, અને ડિસ્ક્રિપ્ટર હજુ પણ પાસવર્ડ સ્પષ્ટ ટેક્સ્ટમાં રાખે છે. સમાધાન સ્પષ્ટ છે: પાસવર્ડ હવે ડિસ્ક પર છે, તેથી એ ડિરેક્ટરીને રહસ્ય તરીકે ગણો, હોસ્ટની બહારના બેકઅપમાંથી બાકાત રાખો, અને માણસ હાજર હોય ત્યારે ઇન્ટરેક્ટિવ માર્ગ પસંદ કરો.
પાસવર્ડ નિષ્ફળતા જેવી દેખાતી બસ નિષ્ફળતા
ક્રેડેન્શિયલને આભારી ગણાતી કેટલીક નિષ્ફળતાઓ એવી જ નથી. સેવાના સક્રિયકરણ માર્ગનું નામ આપતી પરવાનગી ભૂલ બેમાંથી એક બાબતનો અર્થ આપે છે: બેકએન્ડ ચાલુ નથી, અથવા બોલાવનારને તેને સક્રિય કરવાની પરવાનગી નથી. કોઈ પ્રોફાઇલ સંપાદન એમાંથી કંઈ બદલશે નહીં. કન્ફિગરેશનને સ્પર્શ કરતાં પહેલાં સેવાની સ્થિતિ અને સાથે આપેલી બસ નીતિ તપાસો.
નીચેના આદેશો બંનેને અલગ કરે છે. પ્રથમ જણાવે છે કે બેકએન્ડ ચાલુ છે કે નહીં; બીજો તાજેતરની બસ ભૂલો દર્શાવે છે:
systemctl status openvpn3-service-client
journalctl -b -u openvpn3-service-client --no-pager | tail -20
બીજી વારંવાર થતી ખોટી સમજ એવું સેશન છે જે દેખાય છે અને તરત જ અદૃશ્ય થઈ જાય છે. એ પેટર્ન સામાન્ય રીતે બતાવે છે કે સાઇટ-સ્થાનિક સેટિંગ્સ ક્યારેય લાગુ થયા નથી, તેથી ટનલ તેને ઉપયોગી બનાવતા રૂટિંગ અને રિઝોલ્વર ફેરફારો વિના ઉપર આવી. છેલ્લી લાઇન નહીં, ક્રમ વાંચો: સેશન બન્યું કે નહીં, તે જોડાયેલ સ્થિતિ સુધી પહોંચ્યું કે નહીં, અને તે ટકી રહ્યું કે નહીં એ ત્રણ અલગ તથ્યો છે.
જ્યારે જૂનો ક્લાયન્ટ હજુ વપરાય છે
2.x ક્લાયન્ટ હજુ પણ ક્રેડેન્શિયલ ફાઇલ સ્વીકારે છે, અને કીરિંગ તેના પ્રોમ્પ્ટનો જવાબ આપી શકે છે જ્યારે રહસ્ય ક્યારેય ડિસ્ક પર ન પહોંચે. રેપર એન્ટ્રી ઉકેલે છે, તેથી ફાઇલ પાસવર્ડને બદલે લુકઅપનું નામ આપે છે. આ ગોઠવણ અનલૉક કરેલી કીરિંગ પર આધારિત છે, જે લોગિન સેશન વગરનો કન્ટેનર કે કોઈ સાઇન ઇન કરે તે પહેલાં શરૂ થતું યુનિટ પૂરું પાડી શકતું નથી. પછી લુકઅપ સાધન એવા સંગ્રહની જાણ કરે છે જેમાં તે લખી શકતું નથી, તેથી ભૂલ ક્રેડેન્શિયલ ખામી જેવી દેખાય છે જ્યારે તે કીરિંગની ખામી છે.
એમાંથી કંઈ બનાવતાં પહેલાં, તપાસો કે પ્રોફાઇલમાંનું keepalive સેટિંગ ફરી શરૂ કરવાની જરૂરિયાત સંપૂર્ણપણે દૂર કરે છે કે નહીં. ઉપર રહેતું સેશન તમે ઓટોમેટ કરવા માગતા પ્રોમ્પ્ટ સુધી ક્યારેય પહોંચતું નથી.