OpenVPN ഒരു പിശകും കാണിക്കാതെ ആരംഭിക്കുന്നില്ലേ? ജേണൽ നോക്കുക
Ubuntu-യിൽ നിശബ്ദമായ പുറത്തുകടക്കൽ സാധാരണയായി സന്ദേശം മറ്റെവിടെയോ പോയി എന്നോ യൂണിറ്റ് ഒരിക്കലും പ്രവർത്തിച്ചില്ല എന്നോ അർത്ഥമാക്കുന്നു. ആദ്യം ഇൻസ്റ്റൻസിന്റെ പേര്, ജേണൽ, ബൈനറി എന്നിവ പരിശോധിക്കുക.
കമാൻഡ് മടങ്ങുന്നു, സേവനം പരാജയമായി കാണിക്കുന്നു, വിശദീകരണം പോലെയുള്ള ഒന്നും ടെർമിനലിൽ എത്തുന്നില്ല. ഈ നിശബ്ദതയാണ് ആളുകൾ «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 Debian, Ubuntu പാക്കേജിംഗിൽ /etc/openvpn/client/office.conf ആയി പരിഹരിക്കുന്നു. 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 ഫയലിലേക്കോ എന്തെങ്കിലും എത്തിയോ, ഏത് ബൈനറിയും പ്രൊഫൈലും യഥാർത്ഥത്തിൽ പ്രവർത്തിച്ചു, പരാജയം പ്രാദേശികമാണോ വിദൂരമാണോ. ഓരോ ഉത്തരവും ഒരു പാളി നീക്കുന്നു. പ്രൊഫൈലിൽ നിന്ന് ആരംഭിക്കുന്നത് ഒരിക്കലും തുറന്നിട്ടില്ലായിരിക്കാവുന്ന ഒരു ഫയൽ വീണ്ടും എഴുതുന്നതാണ്.