VPN സർവറിന്റെ പ്രവർത്തനസമയം: ആ സംഖ്യ നിങ്ങളോട് എന്ത് പറയുന്നില്ല

ഒരു പൊതു നോഡ് പട്ടിക ആഴ്ചകളിൽ അളക്കുന്ന പ്രവർത്തനസമയമുള്ള ഒരു സർവർ കാണിക്കുന്നു, അതിനാൽ നിങ്ങൾ അത് തിരഞ്ഞെടുക്കുന്നു, ആദ്യ ശ്രമത്തിൽ തന്നെ കണക്ഷൻ പരാജയപ്പെടുന്നു. ഇത് കളവുപറയുന്ന പരസ്യമല്ല; മറ്റൊന്ന് അളക്കുന്ന ഒരു സംഖ്യയോട് ചോദിച്ച തെറ്റായ ചോദ്യമാണ്. പ്രവർത്തനസമയം സാധാരണയായി ഒരു പ്രോസസ്, കണ്ടെയ്നർ അല്ലെങ്കിൽ മെഷീൻ അവസാനമായി ആരംഭിച്ചതിനുശേഷം എത്ര സമയം പ്രവർത്തിക്കുന്നു എന്ന് പറയുന്നു, അത് പ്രകാശകന്റെ അടിസ്ഥാനസൗകര്യത്തിന്റെ സ്വഭാവമാണ്, നിങ്ങളുടെ അങ്ങോട്ടുള്ള പാതയുടെയല്ല. അതിനെ വിശ്വാസ്യതയായി കാണുന്നത് ഒരു കാറിന്റെ ഓഡോമീറ്ററിനെ റോഡ് റിപ്പോർട്ടായി കാണുന്ന അതേ വിഭാഗത്തിലെ പിശകാണ്.

സംഖ്യ എന്ത് അളക്കുന്നു

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

systemctl show -p ActiveEnterTimestamp --value openvpn-server@server
uptime -s
systemctl is-active openvpn-server@server

ആ മൂന്ന് കമാന്റുകൾ മൂന്ന് വ്യത്യസ്ത ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു, ഒരു സംഖ്യ മാത്രം കാണിക്കുന്ന ഒരു ഡയറക്ടറിക്ക് അവയിൽ ഏതാണ് ഉപയോഗിച്ചതെന്ന് പറയാനാകില്ല. അതിനാൽ രണ്ട് പട്ടികകളിലെ അസംസ്കൃത കൗണ്ടർ താരതമ്യം ചെയ്യുന്നത്, ഓരോന്നും എന്തിൽ പുനഃസജ്ജമാക്കുന്നു എന്ന് അറിയുന്നതുവരെ താരതമ്യമേയല്ല.

പാത താഴെയായിരിക്കുമ്പോഴും പ്രോസസ് പ്രവർത്തിക്കാം

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

മറ്റൊരു കാരണത്താൽ ഒരു സർവർ പ്രവർത്തിക്കുകയും ഉപയോഗശൂന്യമാകുകയും ചെയ്യാം. തന്റെ ബാൻഡ്വിഡ്ത്ത് പിന്തുണയ്ക്കുന്നതിലും വളരെ കൂടുതൽ ക്ലയന്റുകളെ സ്വീകരിച്ച ഒരു നോഡ് ദീർഘമായ പ്രവർത്തനസമയവും ഭയാനകമായ അനുഭവവും കാണിക്കും, കാരണം കൗണ്ടർ ശേഷിയോ മത്സരമോ അളക്കുന്നില്ല. ദീർഘമായ പ്രവർത്തനസമയമുള്ള ഒരു നോഡ് നിരാശപ്പെടുത്തുന്ന ഏറ്റവും സാധാരണ വഴി ഇതാണ്: ഒന്നും കേടായിട്ടില്ല, എല്ലാം തിരക്കിലാണ്.

വിപരീത സാഹചര്യവും ഓർക്കേണ്ടതാണ്. ഒരു മണിക്കൂർ മുമ്പ് പുനരാരംഭിച്ച ഒരു നോഡ് ഇപ്പോൾ പൂർണ്ണമായും ആരോഗ്യകരമായിരിക്കാം, ഏറ്റവും വലിയ സംഖ്യ അനുസരിച്ച് അടുക്കുമ്പോൾ അത് നിശബ്ദമായി ഒഴിവാക്കപ്പെടുന്നു. പ്രവർത്തനസമയം ഒരു ഗുണനിലവാര സ്കോർ അല്ല, അതിനെ അങ്ങനെ കാണുന്നത് യോഗ്യതയ്ക്ക് പകരം പ്രായത്തിന്റെ അടിസ്ഥാനത്തിൽ തിരഞ്ഞെടുക്കുന്നു.

പുതുമ: റിപ്പോർട്ട് നിങ്ങളുടെ ശ്രമത്തേക്കാൾ പഴയതാണ്

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

ആ വിടവ് എതിർദിശയിലും പ്രവർത്തിക്കുന്നു. താഴെയാണെന്ന് റിപ്പോർട്ട് ചെയ്ത ഒരു നോഡ് റിപ്പോർട്ട് നിർമ്മിച്ചതിന് കുറച്ച് മിനിറ്റുകൾക്കുശേഷം തിരികെ വന്നിരിക്കാം, അതിനാൽ മറ്റൊരു നോഡിൽ ഉടനടി വീണ്ടും ശ്രമിക്കുന്നത് എല്ലായ്പ്പോഴും മികച്ച തിരഞ്ഞെടുപ്പല്ല.

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

പകരം എന്ത് പരീക്ഷിക്കണം

നോഡിൽ നിന്ന് നിങ്ങൾക്ക് എന്ത് വേണമെന്ന് തീരുമാനിച്ച് അത് പരീക്ഷിക്കുക. എത്തിച്ചേരൽ വേണമെങ്കിൽ, കേൾക്കുന്ന പോർട്ടിലേക്കുള്ള TCP കണക്ഷൻ ശ്രമം ഒരു സെക്കൻഡിൽ ഏത് കൗണ്ടറിനേക്കാളും കൂടുതൽ പറയുന്നു. പ്രവർത്തിക്കുന്ന ഒരു ടണൽ വേണമെങ്കിൽ, ഒന്നിനായി ചർച്ച ചെയ്യുക. ഉപയോഗയോഗ്യമായ ത്രൂപുട്ട് വേണമെങ്കിൽ, യഥാർത്ഥമായ എന്തെങ്കിലും കൈമാറി അത് അളക്കുക, കാരണം കണക്ഷൻ സമയവും ത്രൂപുട്ടും വ്യത്യസ്ത സ്വഭാവങ്ങളാണ്, വേഗത്തിലുള്ള ഹാൻഡ്ഷേക്ക് രണ്ടാമത്തേതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.

nc -vz -w 5 vpn.example.net 1194
curl -sS -o /dev/null -w '%{time_connect} %{time_appconnect} %{time_total}\n' https://vpn.example.net/
mtr -rwc 20 vpn.example.net

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

വഴിതെറ്റിക്കപ്പെടാതെ പൊതു നോഡ് പട്ടികകൾ വായിക്കൽ

പ്രവർത്തനസമയം ആളുകൾ സാധാരണയായി VPN-ൽ നിന്ന് ആഗ്രഹിക്കുന്ന കാര്യങ്ങളെക്കുറിച്ച് യാതൊരു വിവരവും വഹിക്കുന്നില്ല: സർട്ടിഫിക്കറ്റിന്റെ സാധുത, എക്സിറ്റ് ആരാണ് നടത്തുന്നത്, ഏത് DNS നയമാണ് ബാധകമാകുന്നത്, ഓപ്പറേറ്റർ കണക്ഷൻ റെക്കോർഡുകൾ സൂക്ഷിക്കുന്നുണ്ടോയെന്നത്. ഇവ വെവ്വേറെ തെളിവ് ആവശ്യമുള്ള വെവ്വേറെ വാദങ്ങളാണ്, നീണ്ട കൗണ്ടർ അവയൊന്നിനും തെളിവല്ല. ഒരു നോഡ് മാസങ്ങളോളം സ്ഥിരതയുള്ളതായിരിക്കാം, എന്നിട്ടും സ്വകാര്യതാ ആവശ്യത്തിന് മോശം തിരഞ്ഞെടുപ്പായിരിക്കാം.

പട്ടിക യഥാർത്ഥത്തിൽ സഹായിക്കുന്നത് ചെറിയ പട്ടിക തയ്യാറാക്കുമ്പോഴാണ്. നിങ്ങൾക്ക് ആവശ്യമെന്ന് അറിയാവുന്നതിന്റെ അടിസ്ഥാനത്തിൽ അടുക്കുക, ചുമതലയുമായി ബന്ധമില്ലാത്ത പ്രദേശങ്ങളിലെ നോഡുകൾ ഫിൽട്ടർ ചെയ്യുക, തുടർന്ന് ബാക്കിയുള്ള മൂന്നോ നാലോ പരീക്ഷിക്കുക. വെറും ഉവ്വോ ഇല്ലയോ എന്നതിന് പകരം ഓരോ ശ്രമത്തിന്റെയും പരാജയ ഘട്ടം സൂക്ഷിക്കുക, കാരണം «TLS ഹാൻഡ്ഷേക്ക് പരാജയപ്പെട്ടു» എന്നതും «കണക്ട് ചെയ്തു പക്ഷേ ത്രൂപുട്ട് ഇല്ല» എന്നതും തീർത്തും വ്യത്യസ്ത നിഗമനങ്ങളിലേക്ക് നയിക്കുന്നു.

പാതയുടെ പ്രകടനം അളക്കുന്ന ചട്ടക്കൂട് അതേ ആശയം കൂടുതൽ കർശനമായ രൂപത്തിൽ പറയുന്നു: സംഖ്യകൾ ശേഖരിക്കുന്നതിന് മുമ്പ് മെട്രിക്, വ്യവസ്ഥകൾ, രീതി എന്നിവ നിർവചിക്കുക. നോഡ് പട്ടികയിൽ പ്രയോഗിക്കുമ്പോൾ അതിന്റെ അർത്ഥം പ്രവർത്തനസമയ ഫീൽഡ് പശ്ചാത്തലമാണ് എന്നാണ്. നിങ്ങൾ തന്നെ നടത്തുന്ന അളവെടുപ്പാണ് തീരുമാനം.