കണക്ഷൻ എത്ര സമയമായി പ്രവർത്തിക്കുന്നു എന്ന സംഖ്യ ഒരു ഡാഷ്ബോർഡ് ആവശ്യപ്പെടുന്നു, എന്നാൽ OpenVPN അത് നൽകുന്നില്ല। തന്റെ ടണൽ എപ്പോൾ ഉയർന്നു എന്ന് ക്ലയന്റിന് അറിയാം, പക്ഷേ സെഷൻ അവസ്ഥ നഷ്ടപ്പെടുന്നതിന് മുമ്പ് ആരെങ്കിലും ആ നിമിഷം രേഖപ്പെടുത്തിയാൽ മാത്രം। പിന്തുണയ്ക്കുന്ന സ്ഥലം up ഹുക്ക് ആണ്, സൂക്ഷിക്കാൻ യോഗ്യമായ മൂല്യം ഫോർമാറ്റ് ചെയ്ത സ്ട്രിംഗല്ല, അസംസ്കൃത epoch സെക്കൻഡാണ്। അതിനുശേഷമുള്ളതെല്ലാം ഗണിതമാണ്, കൂടാതെ സംഖ്യ സത്യസന്ധമായി നിലനിൽക്കുന്നുണ്ടോ എന്ന് തീരുമാനിക്കുന്ന ചില ക്രമ നിയമങ്ങളും।

ഹുക്കുകൾ യഥാർത്ഥത്തിൽ പ്രവർത്തിക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കുക

അതിനുചുറ്റും എന്തെങ്കിലും രൂപകൽപ്പന ചെയ്യുന്നതിന് മുമ്പ് ഹുക്ക് പ്രവർത്തിക്കുന്നുവെന്ന് തെളിയിക്കുക। കുറഞ്ഞ ക്ലയന്റ് കോൺഫിഗറേഷന് script-security 2 ഉം വ്യക്തമായ പാതകളും up ഉം down ഉം വേണം; സുരക്ഷാ വരിയില്ലാതെ OpenVPN സ്ക്രിപ്റ്റ് പ്രവർത്തിപ്പിക്കാൻ വിസമ്മതിക്കുകയും അത് വ്യക്തമായി പറയുകയും ചെയ്യുന്നു। അതേ സമയം up-restart ഉം down-pre ഉം ചേർക്കുക, അപ്പോൾ റീസ്റ്റാർട്ട്, പൊളിക്കൽ പാതകൾ പ്രവചനാതീതമായി പെരുമാറും।

ഹുക്കിന്റെ ആദ്യ പതിപ്പ് അതിന്റെ പരിസ്ഥിതി ഒരു ഫയലിലേക്ക് ചേർക്കുകയും മറ്റൊന്നും ചെയ്യാതിരിക്കുകയും ചെയ്യുന്നതാക്കുക। ഇത് നിങ്ങളുടെ ബിൽഡ് യഥാർത്ഥത്തിൽ കയറ്റുമതി ചെയ്യുന്ന വേരിയബിൾ പേരുകൾ കാണിക്കുന്നു, ഉദാഹരണത്തിന് dev ഉം script_type ഉം, മറ്റൊരു പതിപ്പിൽ നിന്ന് ഓർമ്മയുള്ള പേരുകൾക്കുപകരം। ഒരു കണക്ഷനും ഒരു വിച്ഛേദവും പ്രവർത്തിപ്പിച്ച് ഫയൽ വായിക്കുക। ഒന്നും കാണാത്തപക്ഷം ഇവിടെ നിർത്തുക, കാരണം ഒരിക്കലും പ്രവർത്തിക്കാത്ത ഹുക്കിന് മേലുള്ള ടൈംസ്റ്റാമ്പ് രൂപകൽപ്പന ആഴ്ചകളോളം നിരീക്ഷണ പരാജയമായി തോന്നും।

ഹുക്ക് ഏത് ഉപയോക്താവായി പ്രവർത്തിക്കുന്നു എന്ന് പരിശോധിക്കുക। user ഉം group ഉം സജ്ജീകരിച്ചാൽ OpenVPN സ്ക്രിപ്റ്റുകൾ പ്രവർത്തിപ്പിക്കുന്നതിന് മുമ്പ് പ്രത്യേകാവകാശങ്ങൾ ഉപേക്ഷിക്കുന്നു, അതിനാൽ root എഴുതാവുന്ന ഡയറക്ടറി ഹുക്കിന് അടച്ചിരിക്കാം। നിങ്ങളുടെ ഷെല്ലിന്റെ കാഴ്ചപ്പാടിൽ നിന്നല്ല, സേവനത്തിന്റെ കാഴ്ചപ്പാടിൽ നിന്ന് പാത തിരഞ്ഞെടുക്കുക।

ഒരു epoch മൂല്യം രേഖപ്പെടുത്തി അത് ബോധപൂർവ്വം മായ്ക്കുക

up ഹുക്കിന് ഒരു വരി വേണം, date +%s > /run/openvpn-client.started, ഓരോ ഇൻസ്റ്റൻസിനും പാത ക്രമീകരിച്ച്। epoch മൂല്യം പിന്നീട് ഭാഷ, സമയമേഖല, ഫോർമാറ്റ് എന്നിവയുടെ ചോദ്യങ്ങൾ ഒഴിവാക്കുന്നു, കൂടാതെ നിരീക്ഷണ ഏജന്റിന് സ്വന്തം ഘടികാരവുമായി താരതമ്യം ചെയ്യാവുന്ന അതേ സംഖ്യയാണിത്।

മായ്ക്കുന്നത് എഴുതുന്നത്ര പ്രധാനമാണ്। down ഹുക്ക് ഫയൽ ശൂന്യമാക്കുകയോ നീക്കം ചെയ്യുകയോ ചെയ്യണം, down-pre ഇന്റർഫേസ് അടയ്ക്കുന്നതിന് മുമ്പ് അത് ചെയ്യുന്നു, ഇത് ഇതിനകം പോയ ടണലിനെ ഫയൽ വിവരിക്കുന്ന ജാലകം ഒഴിവാക്കുന്നു। up-restart പിന്നീട് ആന്തരിക റീസ്റ്റാർട്ടിൽ സ്റ്റാമ്പ് പുതുക്കുന്നു, യഥാർത്ഥ മൂല്യം അവിടെ വിടുന്നതിനുപകരം। ആ ജോടി ഇല്ലാതെ ping കാലഹരണത്തിന് ശേഷമുള്ള റീസ്റ്റാർട്ട് ടണൽ വീണ്ടും സ്ഥാപിക്കുന്നതിനിടയിൽ കയറിക്കൊണ്ടിരിക്കുന്ന സംഖ്യ നൽകുന്നു।

ശരിയായ ആയുസ്സുള്ള സ്ഥലം തിരഞ്ഞെടുക്കുക। /run ക്ക് കീഴിലുള്ള ഫയൽ റീബൂട്ടിൽ അപ്രത്യക്ഷമാകുന്നു, ഇത് യാഥാർത്ഥ്യവുമായി പൊരുത്തപ്പെടുന്നു, അതേസമയം /tmp ക്ക് കീഴിലുള്ള ഫയൽ പ്രവചനാതീതമായി വൃത്തിയാക്കപ്പെടാം, കോൺഫിഗറേഷൻ ഡയറക്ടറിയിലുള്ളത് തെറ്റിദ്ധരിപ്പിക്കുന്ന രീതിയിൽ നിലനിൽക്കുന്നു। സേവന ഉപയോക്താവിനും നിരീക്ഷണ വായനക്കാരനും മാത്രം വായിക്കാൻ അനുമതികൾ സജ്ജീകരിക്കുക।

ലോഗ് വരികളെ വിശ്വസിക്കാതെ പ്രവർത്തനസമയം കണക്കാക്കുക

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

ലോഗ് ടൈംസ്റ്റാമ്പുകൾ പാഴ്സ് ചെയ്യുന്നത് പ്രലോഭനീയമായ ചെറുപാതയാണ്, അത് മൂന്ന് തരത്തിൽ പരാജയപ്പെടുന്നു: ഫോർമാറ്റ് സജ്ജീകരിച്ച ഏത് ഓപ്ഷനുകളെയും പിന്തുടരുന്നു, റൊട്ടേഷൻ ചരിത്രം നീക്കം ചെയ്യുന്നു, വീണ്ടും കണക്ഷനുകൾ ഒരു തുടർച്ചയായ ടണലിനുപകരം വേറിട്ട സെഷനുകളായി പ്രത്യക്ഷപ്പെടുന്നു। ഹുക്ക് സംഭവം ഒരിക്കൽ മാത്രം, അത് സംഭവിക്കുന്ന നിമിഷത്തിൽ രേഖപ്പെടുത്തുന്നു।

പരിശോധന മറ്റൊരു ഹോസ്റ്റിൽ പ്രവർത്തിക്കുമ്പോൾ, ദൈർഘ്യത്തിനുപകരം ടൈംസ്റ്റാമ്പ് അയയ്ക്കുക, വായനക്കാരൻ സ്വന്തം ഘടികാരം പ്രയോഗിക്കട്ടെ। അപ്പോൾ ചെറിയ നെഗറ്റീവ് ഫലം തകർന്ന ഹുക്കായല്ല, ഘടികാര വ്യത്യാസമായി വായിക്കപ്പെടുന്നു।

വീണ്ടും കണക്ഷനുകൾ, റീസ്റ്റാർട്ടുകൾ, ഒന്നിലധികം ഇൻസ്റ്റൻസുകൾ എന്നിവ ഉൾക്കൊള്ളുക

ഒരു ഹോസ്റ്റിലെ രണ്ട് ടണലുകൾക്ക് രണ്ട് ഫയലുകൾ വേണം, സേവനം ഇതിനകം ഉപയോഗിക്കുന്ന ഇൻസ്റ്റൻസ് പേരാണ് കീ। പങ്കിട്ട പാത എന്നാൽ ഏറ്റവും പുതിയ കണക്ഷൻ ഓരോ പ്രൊഫൈലിന്റെയും ആരംഭ സമയം മേലെഴുതുന്നു, രണ്ടാമത്തെ ടണൽ ആരംഭിക്കുമ്പോൾ സംഖ്യ പിന്നോട്ട് ചാടുന്നതാണ് ലക്ഷണം।

വീണ്ടും കണക്ഷന്റെ പെരുമാറ്റം പ്രത്യേക പരീക്ഷണത്തിന് അർഹമാണ്, കാരണം അവിടെയാണ് യുക്തിസഹമെന്ന് തോന്നുന്ന രൂപകൽപ്പന നിശബ്ദമായി തെറ്റായത് റിപ്പോർട്ട് ചെയ്യുന്നത്। പിയർ വീഴ്ത്തിയോ പ്രോസസ്സിന് സിഗ്നൽ അയച്ചോ റീസ്റ്റാർട്ട് നിർബന്ധമാക്കി, ഇന്റർഫേസ് അവസ്ഥ ഫയലുമായി താരതമ്യം ചെയ്യുക। ടണൽ തിരികെ വരുന്ന നിമിഷത്തിൽ ടൈംസ്റ്റാമ്പ് മുന്നോട്ട് നീങ്ങണം।

സെർവർ വശത്ത്, സ്റ്റാറ്റസ് ഫയൽ ഓരോ ക്ലയന്റിനും connected-since മൂല്യം വഹിക്കുന്നു, അത് മറ്റൊരു ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു: സെർവർ ആ പിയറിനെ അവസാനമായി കണ്ടത് എപ്പോൾ। അത് പകരമായല്ല, ക്രോസ്-ചെക്കിനായി ഉപയോഗിക്കുക, കാരണം അത് വിവരിക്കുന്ന സെഷനോടൊപ്പം അപ്രത്യക്ഷമാകുന്നു। രണ്ട് അളവുകളും ടണലിന് പിന്നിലെ ആപ്ലിക്കേഷന്റെ ആരോഗ്യത്തെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല।

ക്രമ തകരാറുകൾ പിടികൂടുന്ന മൂന്ന് പരിശോധനകൾ പ്രവർത്തിപ്പിക്കുക

സാധാരണ കണക്ഷൻ, നിർബന്ധിത വീണ്ടും കണക്ഷൻ, വൃത്തിയുള്ള നിർത്തൽ എന്നിവ പരീക്ഷിക്കുക, ഓരോന്നിനും ശേഷം ഇന്റർഫേസ് പട്ടികയും ഫയലും ഒരുമിച്ച് വായിക്കുക। വൃത്തിയുള്ള നിർത്തലിന് ശേഷവും അവശേഷിക്കുന്ന സ്റ്റാമ്പ്, അല്ലെങ്കിൽ ഇന്റർഫേസ് പട്ടികയിലില്ലാത്ത ടണൽ അവകാശപ്പെടുന്ന ഫയൽ, നേരെ ഹുക്ക് ക്രമത്തിലേക്ക് ചൂണ്ടുന്നു। പരിശോധനകൾ സേവന ഉപയോക്താവായും സേവനത്തിന്റെ പാതകളിലും പ്രവർത്തിപ്പിക്കുക, കാരണം root ഷെല്ലിന് മറ്റൊരു ഫയൽ കാണാനും ആത്മവിശ്വാസത്തോടെ തെറ്റായ ഉത്തരം നൽകാനും കഴിയും। പിന്നീട് സാവധാനത്തിലുള്ള ഒരു പോളറിനെ ഫയൽ വായിക്കാൻ വിടുക, അതിൽ ഒരിക്കലും എഴുതുന്നില്ലെന്ന് ഉറപ്പാക്കുക।

അറുപത് സെക്കൻഡിലൊരിക്കൽ ഉള്ള ഒരു പോൾ മുന്നറിയിപ്പുകൾ ഉൾക്കൊള്ളുന്നു, ആ പോളർ ജീവിച്ചിരിക്കുന്നു എന്നതിനെ ഏത് ഹുക്കും ആശ്രയിക്കരുത്। ഈ രണ്ട് ഉത്തരവാദിത്തങ്ങൾ വേറിട്ട് നിർത്തുക, ഏത് വശം വീണ്ടും വിന്യസിച്ചാലും സംഖ്യ വിശ്വസനീയമായി തുടരും।

അനുബന്ധ ലേഖനങ്ങൾ