OpenVPN ആരംഭിച്ചെങ്കിലും ഒന്നും പ്രിന്റ് ചെയ്തില്ല: ആദ്യം log-append പരിശോധിക്കുക

ഒരു കോൺഫിഗറേഷൻ ഫയലോടെ ഷെല്ലിൽനിന്ന് OpenVPN ആരംഭിക്കുമ്പോൾ ടെർമിനൽ ഒന്നും പ്രിന്റ് ചെയ്യാതെ നിൽക്കുന്നു. ബാനറില്ല, പിശകില്ല, ഇൻപുട്ടിനുള്ള സൂചനയുമില്ല. ആരംഭം പരാജയപ്പെട്ടു എന്നാണ് തോന്നൽ, അതിനാൽ നിങ്ങൾ മറ്റൊരു പകർപ്പ് ആരംഭിക്കുന്നു, പിന്നെ മറ്റൊന്ന്, ഒടുവിൽ യന്ത്രത്തിൽ പകുതി കോൺഫിഗർ ചെയ്ത നിരവധി പകർപ്പുകൾ അവശേഷിക്കുന്നു. അതിനുമുമ്പ്, ലോഗ് മറ്റൊരിടത്തേക്ക് തിരിച്ചുവിട്ട ഒരു ഡയറക്ടീവ് പ്രൊഫൈലിൽ ഉണ്ടോ എന്ന് പരിശോധിക്കുക. നിശ്ശബ്ദത കൺസോളിന്റെ സ്വഭാവമാണ്, പ്രോസസിന്റേതല്ല.

നിശ്ശബ്ദതയ്ക്ക് രണ്ട് വ്യത്യസ്ത വിശദീകരണങ്ങളുണ്ട്

ഒന്നാമത്തേത്, പ്രോസസ് കൃത്യമായി പ്രവർത്തിക്കുകയും നിങ്ങൾ നിരീക്ഷിക്കാത്ത ഒരു ഫയലിലേക്ക് എഴുതുകയും ചെയ്യുന്നു എന്നതാണ്. രണ്ടാമത്തേത്, അത് ഉടൻതന്നെ അതേ ഫയലിൽ രേഖപ്പെടുത്തിയ പിശകോടെ പുറത്തുപോയി എന്നതാണ്.

രണ്ടും ഒരു ശൂന്യമായ ടെർമിനൽ അവശേഷിപ്പിക്കുന്നു, ഒരു ചോദ്യം അവയെ വേർതിരിക്കുന്നു: ഇപ്പോൾ ഒരു പ്രോസസ് ഉണ്ടോ, അതിനോട് എഴുതാൻ പറഞ്ഞ ഫയലിൽ എന്താണ് ഉള്ളത്. കോൺഫിഗറേഷനിൽ വീണ്ടും തൊടുന്നതിന് മുമ്പ് അതിന് ഉത്തരം നൽകുക. ഔട്ട്പുട്ട് ലഭിക്കാൻ വീണ്ടും ആരംഭിക്കുന്നതാണ് രണ്ട് പകർപ്പുകൾ ഒരു ടണൽ ഉപകരണത്തിനും ഒരേ പോർട്ടിനും വേണ്ടി കലഹിക്കാൻ തുടങ്ങുന്നത്; അത് യഥാർത്ഥ പ്രശ്നവുമായി ബന്ധമില്ലാത്ത പിശകുകൾ സൃഷ്ടിക്കുന്നു.

ഡയറക്ടീവ് കണ്ടെത്തുക, തുടർന്ന് പ്രോസസ് കണ്ടെത്തുക.

ps -o pid,args= -C openvpn
grep -nE '^\s*(log|log-append|cd|daemon|verb)\b' /etc/openvpn/server/server.conf

പ്രവർത്തിക്കുന്ന പ്രോസസ് ഉപയോഗിക്കുന്ന ലക്ഷ്യസ്ഥാനം കണ്ടെത്തുക

പ്രോസസ് യഥാർത്ഥത്തിൽ ആരംഭിച്ച പ്രൊഫൈൽ വായിക്കുക, നിങ്ങൾ തിരുത്തിയതല്ല. സേവനം നിയന്ത്രിക്കുന്ന ഒരു പകർപ്പ് സാധാരണയായി മറ്റൊരു പാത്ത് ലോഡ് ചെയ്യുകയും മറ്റൊരു പ്രവർത്തന ഡയറക്ടറിയിൽ പ്രവർത്തിക്കുകയും ചെയ്യുന്നു, അതിനാൽ ഒരു ആപേക്ഷിക ഫയൽനാമം നിങ്ങൾ പ്രതീക്ഷിക്കാത്ത ഇടത്ത് വിശദീകരിക്കപ്പെടുന്നു.

വ്യക്തമായ ഒരു cd ഡയറക്ടീവ് ആ വ്യത്യാസം കൂടുതൽ മൂർച്ചയുള്ളതാക്കുന്നു, കാരണം ആപേക്ഷിക പാത്ത് ഡയറക്ടറി മാറ്റത്തിനൊപ്പം നീങ്ങുന്നു. ഈ കോൺഫിഗറേഷൻ നിങ്ങൾക്ക് പിന്തുടർച്ചയായി ലഭിച്ചതാണെങ്കിൽ, ഫയൽ ഇപ്പോൾ ആരും അന്വേഷിക്കാത്ത ഒരിടത്ത് കിടക്കാം.

ഫയലിന്റെ മാറ്റസമയം നിങ്ങൾ ആരംഭിച്ച നിമിഷവുമായി താരതമ്യം ചെയ്യുക. കഴിഞ്ഞ ആഴ്ചയിലെ ലോഗ് കഴിഞ്ഞ ആഴ്ചയെക്കുറിച്ചുള്ള തെളിവാണ്. തുടർന്ന് മാറിയ ഫയലിന്റെ അവസാന വരികൾ വായിക്കുക, അവിടെയുള്ളതിനെ നിങ്ങൾക്ക് നഷ്ടമായ ആരംഭ സന്ദേശമായി കണക്കാക്കുക.

log അല്ലെങ്കിൽ log-append: തെളിവും മായ്ക്കലും

log-append ഇതിനകം ഫയലിൽ ഉള്ളതിലേക്ക് കൂട്ടിച്ചേർക്കുന്നു. log ഫയൽ എഴുതാൻ തുറക്കുകയും അതിന്റെ ഉള്ളടക്കം വെട്ടിച്ചുരുക്കുകയും ചെയ്യുന്നു, അതിനാൽ രണ്ടിനുമിടയിൽ മാറുന്നത് നിങ്ങൾ വായിക്കാൻ പോകുന്ന റൺ നീക്കിക്കളയാം.

ഡീബഗ് ചെയ്യുമ്പോൾ ആരെങ്കിലും ഡയറക്ടീവ് മാറ്റിയെങ്കിൽ, മുമ്പത്തെ തെളിവ് ഇതിനകം പോയി, ഫയലിന്റെ വലുപ്പം സംശയാസ്പദമായി ചെറുതായി കാണപ്പെടും. രണ്ട് റണ്ണുകൾ താരതമ്യം ചെയ്ത് എന്തോ മാറി എന്ന് നിഗമനം ചെയ്യുന്നതിന് മുമ്പ് അത് അറിയേണ്ടതുണ്ട്. ഒരു ലോഗ് ഉദ്ദേശപൂർവ്വം ഇല്ലാതാക്കുകയോ സൂക്ഷിക്കുകയോ ചെയ്യുക, പക്ഷേ ഏതാണ് ചെയ്തതെന്ന് അറിയുക. ബോധപൂർവ്വം നീക്കിയ തെളിവ് അബദ്ധത്തിൽ നഷ്ടപ്പെട്ട തെളിവിനേക്കാൾ എളുപ്പം മനസ്സിലാക്കാം.

ഒരു ഓപ്ഷനും കാണാത്ത പിതൃ ഡയറക്ടറികൾ സൃഷ്ടിക്കുന്നില്ല, ഫയൽ വ്യവസ്ഥയുടെ അനുമതികളിലൂടെയോ സേവന സാൻഡ്ബോക്സിലൂടെയോ പ്രവേശനം നൽകുന്നുമില്ല. കോൺഫിഗറേഷനിൽ ശരിയായി തോന്നുന്ന ഒരു പാത്ത് ഡീമൺ പ്രവർത്തിക്കുന്ന അക്കൗണ്ടിന് എഴുതാൻ കഴിയാത്തതായിരിക്കാം, അപ്പോൾ ഡീമൺ ഒന്നും റിപ്പോർട്ട് ചെയ്യുന്നതിന് മുമ്പ് പരാജയപ്പെടാം. ഫയൽനാമമാണ് പ്രശ്നം എന്ന് കരുതുന്നതിന് മുമ്പ് ഡയറക്ടറി നിലനിൽക്കുന്നുണ്ടോ എന്നും അതിന്റെ ഉടമ ആരാണെന്നും പരിശോധിക്കുക.

ഒരു സേവന റാപ്പർ ഔട്ട്പുട്ട് പിടിച്ചെടുക്കുമ്പോൾ

systemd-യിൽ, വ്യക്തമായ ഒരു ഫയൽ ഡയറക്ടീവിന് മുൻഗണന ലഭിച്ചില്ലെങ്കിൽ സാധാരണ ഔട്ട്പുട്ടും പിശകുകളും ജേണലിലേക്ക് പോകുന്നു, കൂടാതെ നിർമ്മാതാവിന്റെ റാപ്പർ അവയെ തികച്ചും വേറെയൊരിടത്ത് പിടിച്ചെടുത്തേക്കാം.

അതുകൊണ്ടാണ് ഒരേ പ്രൊഫൈൽ ഒരു ഷെല്ലിൽനിന്നും ഒരു യൂണിറ്റിൽനിന്നും വ്യത്യസ്തമായി പെരുമാറുന്നത്. യൂണിറ്റിന്റെ പരിതസ്ഥിതി, അതിന്റെ പ്രവർത്തന ഡയറക്ടറി, അതിന്റെ സാധാരണ പ്രവാഹങ്ങൾ എന്നിവ നിങ്ങളുടെ ഇന്ററാക്ടീവ് ഷെല്ലിൽനിന്ന് വ്യത്യസ്തമാണ്. ഒരു ആപേക്ഷിക പാത്ത് ഒരു സന്ദർഭത്തിൽ വിശദീകരിക്കപ്പെടാം, മറ്റൊന്നിൽ എവിടെയും എത്തിച്ചേരാം. രണ്ടും യോജിക്കാതിരിക്കുമ്പോൾ പ്രൊഫൈലല്ല, യൂണിറ്റ് നിർവചനമാണ് വായിക്കേണ്ടത്.

ഒരു പകർപ്പ് കേടായതാണെന്ന് നിഗമനം ചെയ്യുന്നതിനുപകരം രണ്ട് ആരംഭ ക്രമീകരണങ്ങളും താരതമ്യം ചെയ്യുക. യൂണിറ്റിന്റെ കമാൻഡ് ലൈനും അതിന്റെ പരിതസ്ഥിതിയും വായിക്കുക, തുടർന്ന് അതേ സമയ വിൻഡോയിലെ ജേണൽ വായിക്കുക. റാപ്പർ ഔട്ട്പുട്ട് സ്വന്തം ഫയലിലേക്ക് തിരിച്ചുവിടുന്നുവെങ്കിൽ, ആ ഫയലാണ് ഇപ്പോൾ നിങ്ങളുടെ ലോഗ്, സന്ദേശങ്ങൾ എവിടെ പോയി എന്നതിന് OpenVPN ഡയറക്ടീവുകൾ പ്രസക്തമല്ല.

വിശദാംശ നില കൂട്ടുക, അത് വായിക്കാൻ കഴിഞ്ഞതിനുശേഷം മാത്രം

ലക്ഷ്യസ്ഥാനം കണ്ടെത്തുന്നതിന് മുമ്പ് വിശദാംശ നില കൂട്ടുന്നത് നിങ്ങൾ നോക്കാത്ത ഒരിടത്ത് കൂടുതൽ വാചകം മാത്രം സൃഷ്ടിക്കുന്നു.

ഔട്ട്പുട്ട് എവിടെ എത്തുന്നു എന്ന് അറിഞ്ഞാൽ, മിതമായ ഒരു നില പ്രൊഫൈൽ പാഴ്സ് ചെയ്യുന്നതും കണക്ഷൻ ശ്രമിക്കുന്നതും കാണിക്കുന്നു. ആരംഭ പ്രശ്നത്തിന് രണ്ടോ മൂന്നോ മതി. കൂടുതൽ ഉയർന്ന നിലകൾ പരാജയം ഒരു ചർച്ചാ വിശദാംശമായിരിക്കുമ്പോൾ സ്ഥാനം അർഹിക്കുന്നു, അവ ഫയൽ വേഗത്തിൽ വളരാൻ കൂടി ഇടയാക്കുന്നു.

തുടർന്ന് യഥാർത്ഥ പിശക് വായിക്കുക. ടണൽ ഉയർന്നോ എന്നതിനെക്കുറിച്ച് നിശ്ശബ്ദമായ ടെർമിനൽ ഒന്നും തെളിയിക്കുന്നില്ല, ഫയലിൽ രേഖപ്പെടുത്തിയ പരാജയമാണ് പരിഹരിക്കേണ്ടത്.