OpenVPN active (exited) કહે છે? તમે શરૂ કરેલું ઇન્સ્ટન્સ શોધો

તમે ટનલ તપાસો છો, systemctl status openvpn ચલાવો છો અને Main PID વગર તથા ખાલી પ્રોસેસ યાદી સાથે active (exited) મેળવો છો. સ્વાભાવિક વાંચન એ છે કે સેવા શરૂ થઈ અને મરી ગઈ, તેથી તમે યુનિટ ખોલો છો, /bin/true શોધો છો અને પેકેજ તૂટેલું છે તેવું તારણ કાઢો છો. Debian પેકેજિંગમાં એ સ્થિતિ wrapper છે જે ડિઝાઇન મુજબ કામ કરે છે, અને ટનલ એ શરૂ કરેલા instance યુનિટમાંથી એકમાં રહે છે. સમગ્ર યુનિટ તમને કદી નહીં કહે કે કયા ઇન્સ્ટન્સે તેને બનાવ્યું.

આ યુનિટ પર active (exited) નો ખરેખર શું અર્થ છે

પેકેજ કરેલું યુનિટ એક-વારનું કામ છે: તેનું ExecStart /bin/true છે, અને RemainAfterExit=yes એ છે જે પૂર્ણ થયેલા યુનિટને active (exited) તરીકે જણાવાયેલું રાખે છે. એ નિર્દેશ દૂર કરો તો એ જ સફળ /bin/true કામગીરી inactive (dead) માં પૂરી થાય છે, જે બરાબર એ સ્થિતિ છે જે લોકો અપેક્ષા રાખે છે અને વિરુદ્ધ દિશામાં ખોટી વાંચે છે. આદેશ માત્ર જગ્યા રાખનાર છે, અને યુનિટ બીજા યુનિટ કરતાં કામનો અહેવાલ આપે છે. એ ગોઠવણમાં કંઈ તૂટેલું નથી, અને /bin/true બદલવાથી ટનલ નહીં પણ પેકેજિંગ કરાર બદલાય છે.

wrapper સોંપણી કરે છે. પેકેજ રૂપરેખા અથવા તેના systemd જનરેટર પૂરા પાડે તે instance યુનિટ શરૂ કરે છે, તેથી ખાલી પ્રોસેસ યાદી ટનલ વિશે કંઈ સાબિત કરતી નથી. જ્યારે કોઈ ઇન્સ્ટન્સ પસંદ ન હોય, ત્યારે પણ wrapper સફળ થાય છે અને ત્યારે પણ કંઈ શરૂ કરતું નથી. સ્થિતિ જવાબ આપે છે કે wrapper ચાલ્યું કે નહીં, ટનલ છે કે નહીં તે નહીં.

કૌંસમાંના શબ્દને બદલે status આઉટપુટની ત્રણ લીટીઓ વાંચો. Loaded systemd એ વાંચેલી યુનિટ ફાઇલનું નામ આપે છે, Active છેલ્લા સફળ રનની સમયમુદ્રા ધરાવે છે, અને Main PID ની ગેરહાજરી પૂરી થયેલી એક-વારની કામગીરી સાથે મેળ ખાય છે. એ ત્રણ લીટીઓ જ આ wrapper ને શરૂ થયાની એક સેકન્ડ પછી પડી ગયેલી સેવાથી અલગ પાડવાનો રસ્તો છે.

status ફરી વાંચતા પહેલાં યુનિટની યાદી બનાવો

શું ચાલી રહ્યું છે તે પૂછતા પહેલાં systemd ને પૂછો કે શું અસ્તિત્વમાં છે. કોઈ ઇન્સ્ટન્સ બન્યા વગર ટેમ્પલેટ સ્થાપિત હોઈ શકે છે, અને ફક્ત બનેલું યુનિટ જ ટનલ ધરાવે છે. લોડ થયેલા સેટથી શરૂ કરો:

systemctl list-units 'openvpn*'

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

systemctl list-unit-files 'openvpn*'

બંને યાદીઓ સાથે વાંચો, કારણ કે બીજીમાં ટેમ્પલેટ અને પહેલીમાં ઇન્સ્ટન્સ બે જુદા જવાબો છે. અસ્તિત્વમાં રહેલું ટેમ્પલેટ અને ચાલતું ઇન્સ્ટન્સ એક જ હકીકત નથી, અને ફક્ત બીજું જ ટનલ બોલે છે. પેકેજ લેઆઉટ ડિસ્ટ્રિબ્યુશન અને OpenVPN આવૃત્તિઓ વચ્ચે પણ બદલાય છે. જૂનું openvpn@ ટેમ્પલેટ, અલગ client અને server જોડી અને ડિસ્ટ્રિબ્યુશન wrapper એ બધા પોતાના પેકેજિંગમાં માન્ય હોઈ શકે છે.

તમે શોધેલા ટ્યુટોરિયલને નહીં, તમારા મશીનને અનુરૂપ થાઓ. બીજાના આઉટપુટમાં ઇન્સ્ટન્સનું નામ office હોઈ શકે જ્યારે તમારું home અથવા work હોય. જે પસાર થાય છે તે પદ્ધતિ છે, સ્ટ્રિંગ નહીં.

ઇન્સ્ટન્સના નામ પાછળ તે જે ફાઇલ વાંચે છે ત્યાં સુધી જાઓ

upstream client ટેમ્પલેટમાં યુનિટનું કાર્ય ડિરેક્ટરી /etc/openvpn/client છે અને તેનો આદેશ ત્યાંથી %i.conf લે છે, તેથી openvpn-client@office /etc/openvpn/client/office.conf વાંચે છે. ઉદાહરણ પર ભરોસો રાખવાને બદલે સ્થાપિત યુનિટ પર એ મેપિંગની ખાતરી કરો, કારણ કે તમારું ટેમ્પલેટ જૂનું અથવા ડિસ્ટ્રિબ્યુશનનું પુનર્લેખન હોઈ શકે છે:

systemctl cat [email protected]

એ આઉટપુટના તળિયે દેખાતા drop-in વાંચો, કારણ કે .d/ હેઠળની ફાઇલ ExecStart, કાર્ય ડિરેક્ટરી અથવા રૂપરેખા માર્ગ બદલી શકે છે. તમે office.ovpn તરીકે ડાઉનલોડ કરેલી પ્રોફાઇલ ઇન્સ્ટન્સ જે ફાઇલ ખોલે છે તે નથી. એ ખાલી જગ્યા જ સામાન્ય કારણ છે કે ભૂલ એવો માર્ગ નામ આપે છે જે તમે કદી સંપાદિત કર્યો નથી.

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

તેને શરૂ કરો, પછી એ ઇન્સ્ટન્સનો જર્નલ વાંચો

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

sudo systemctl start [email protected]
journalctl -u [email protected] -b

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

એ જ ટનલ પર બીજું મેનેજર ન મૂકો

NetworkManager અને OpenVPN 3 સેશન મેનેજરો પોતાની જોડાણ સ્થિતિ ધરાવે છે, અને તેમાંથી એકની બાજુમાં systemd ઇન્સ્ટન્સ એ જ ટનલ પર બે માલિક મૂકે છે. લક્ષણ એ છે કે ટનલ ઉપર આવે અને થોડી સેકન્ડ પછી બદલાઈ જાય, અથવા અટકેલી રહેવાનો ઇનકાર કરે. તમારું ડિસ્ટ્રિબ્યુશન ડેસ્કટોપ માટે જે મેનેજરનું દસ્તાવેજીકરણ કરે તે પસંદ કરો, અને સર્વર પર systemd જાણી જોઈને વાપરો.

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

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