OpenVPN કોઈ ભૂલ વિના શરૂ થતું નથી? જર્નલ જુઓ

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

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

મૌનનો અર્થ એ છે કે તમે યોગ્ય ચેનલ જોતા ન હતા

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

systemctl status openvpn-client@office
journalctl -u openvpn-client@office -b --no-pager

ઉમેરો systemctl show -p Result -p ExecMainStatus openvpn-client@office સ્વચ્છ નિકાસને સિગ્નલથી અલગ કરવા માટે. સ્થિતિ 1 અને Result=exit-code એ પ્રોગ્રામનો નિર્ણય છે; Result=signal અથવા ટાઇમઆઉટ તેના બદલે પર્યાવરણ તરફ સંકેત કરે છે, અને પ્રોફાઇલ સંપાદનની કોઈ પણ માત્રા તેને બદલશે નહીં. કંઈ પણ પુનઃપ્રારંભ કરતાં પહેલાં બંને મૂલ્યો નોંધો, કારણ કે પુનઃપ્રારંભ તે ક્ષણિક સ્થિતિને ભૂંસી નાખે છે જેણે તેમને ઉત્પન્ન કરી.

ઇન્સ્ટન્સનું નામ પાથનો ભાગ છે

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

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

ls -l /etc/openvpn/client/
systemctl list-units 'openvpn*' --all

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

જ્યારે પ્લગઇન ટનલ ધરાવે છે, ત્યારે ટર્મિનલ કંઈ જોતું નથી

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

જર્નલમાં એ સેવા શોધો જે તેને ધરાવે છે, પછી તમે વાંચી શકો એવી વિગત સાથે પાર્સિંગનું પુનઃઉત્પાદન કરો. નીચેના બે કમાન્ડ એક જ નિષ્ફળતાના અલગ અલગ માલિકો તરફ જુએ છે.

journalctl -b -u NetworkManager --no-pager | grep -i -A3 openvpn
openvpn --config /etc/openvpn/client/office.conf --verb 4 --log /tmp/ovpn.log

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

બે બાઇનરી, એક PATH

હાથે બનાવેલી ઇન્સ્ટોલેશન જે /usr/local હેઠળ છે તે શેલ કૉલમાં જીતે છે, કારણ કે /usr/local/sbin ડિફૉલ્ટ Ubuntu PATH પર /usr/sbin પહેલાં આવે છે. યુનિટ તમારા PATHનો ઉપયોગ કરતું નથી; તે ExecStart માં લખેલો નિરપેક્ષ પાથ ચલાવે છે. તેથી તમારા ટર્મિનલમાં કામ કરતી આવૃત્તિ અને સેવા તરીકે નિષ્ફળ થતી આવૃત્તિ ખરેખર અલગ પ્રોગ્રામ હોઈ શકે છે.

કંઈ પણ ફરી બનાવતાં પહેલાં બંનેની સરખામણી કરો. ત્રીજો કમાન્ડ જ દલીલ નક્કી કરે છે.

command -v openvpn
whereis openvpn
systemctl cat openvpn-client@office | grep ExecStart

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

એ નિષ્ફળતાઓ જે ક્લાયન્ટ જણાવી શકતું નથી

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

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

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