OpenVPN അക്കൗണ്ടിന് പ്രതിമാസ ഡാറ്റാ ക്വോട്ട എവിടെ വേണം

ടണൽ വീണ്ടും കണക്ട് ചെയ്യുമ്പോഴെല്ലാം പുനഃസജ്ജമാകുന്ന ക്വോട്ട ഒരു പരിധിയല്ല, ശാശ്വതമായ അവസ്ഥ സൂക്ഷിക്കാൻ ഇടമില്ലാതെ VPN സെർവറിൽ ബൈറ്റ് കൗണ്ടർ ബോൾട്ട് ചെയ്യുമ്പോൾ കൃത്യമായി അതാണ് ലഭിക്കുന്നത്. കൗണ്ടർ ഒരു സെഷനിൽപ്പെട്ടതാണ്; ക്വോട്ട ഒരു വ്യക്തിയുടെയോ ഉപകരണ കരാറിന്റെയോ ആണ്. ഈ സവിശേഷതയിലെ എല്ലാ ബുദ്ധിമുട്ടും ആ പൊരുത്തക്കേടിൽ നിന്നാണ് വരുന്നത്, അതിനാൽ താഴെയുള്ള പരിശോധനകൾ അവസ്ഥ എവിടെ താമസിക്കുന്നു, ഏത് പാളിക്കാണ് തീരുമാനമെടുക്കാൻ അനുവാദമുള്ളത് എന്നിവയെക്കുറിച്ചാണ്.

ക്വോട്ട ടണലിലല്ല, അക്കൗണ്ടിൽ ഉറപ്പിക്കുക

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

അനുവദിച്ച ടണൽ വിലാസം ഒരിക്കലും ഉത്തരമല്ല. വിലാസങ്ങൾ പുനരുപയോഗിക്കുന്നു, പൂളുകൾ പങ്കിടുന്നു, ഒരേ അക്കൗണ്ട് ഒരേ മിനിറ്റിൽ രണ്ട് ഗേറ്റ്വേകളിൽ രണ്ടുതവണ പ്രത്യക്ഷപ്പെടാം. ലെഡ്ജർ വിലാസത്തെ അടിസ്ഥാനമാക്കിയാൽ, ടാങ്ക് വീണ്ടും നിറയ്ക്കാൻ വിച്ഛേദിച്ച് വീണ്ടും ബന്ധിപ്പിക്കുന്നത് മതി.

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

യൂണിറ്റ്, ദിശ, പുനഃസജ്ജീകരണ അതിർത്തി എന്നിവ നിർണ്ണയിക്കുക

ഏതെങ്കിലും ശേഖരണം തുടങ്ങുന്നതിന് മുൻപ് നാല് നിർവചനങ്ങൾ എഴുത്തിൽ നിർണ്ണയിക്കണം. ക്ലൈന്റ് അയയ്ക്കുന്ന ബൈറ്റുകളാണോ, സ്വീകരിക്കുന്ന ബൈറ്റുകളാണോ, രണ്ടിന്റെയും തുകയാണോ ക്വോട്ട കണക്കാക്കുന്നത്? ഒരു ഗിഗാബൈറ്റ് 10^9 ബൈറ്റാണോ 2^30 ആണോ? ഏത് പ്രാദേശിക മണിക്കൂറിലും ഏത് സമയ മേഖലയിലുമാണ് കാലയളവ് തിരിയുന്നത്? കൂടാതെ കൗണ്ടർ കൃത്യമായി എന്താണ് അളക്കുന്നത്, ടണൽ ഓവർഹെഡും പുനഃപ്രക്ഷേപണങ്ങളും ഉൾപ്പെടുന്നു, എന്നാൽ ആപ്ലിക്കേഷൻ ഫയൽ വലിപ്പവും ദാതാവിന്റെ ബില്ലും ഉൾപ്പെടുന്നില്ല?

ഈ തിരഞ്ഞെടുപ്പുകളിൽ ഒന്നും തെറ്റല്ല, എന്നാൽ നടപ്പാക്കലും ഉപഭോക്താവ് കാണുന്ന സംഖ്യയും യോജിക്കണം. ഒരേ സിസ്റ്റത്തിന്റെ രണ്ട് പകുതികൾ GiB സംബന്ധിച്ചോ പ്രാദേശിക സമയത്തിനു പകരം UTC അർദ്ധരാത്രിയിൽ സംഭവിക്കുന്ന മാറ്റം സംബന്ധിച്ചോ യോജിക്കുന്നില്ലെങ്കിൽ, മുഴുവൻ ക്വോട്ടയിലുമുള്ള വിശ്വാസം ക്ഷയിപ്പിക്കുന്ന അതേ തരം ടിക്കറ്റ് ഉണ്ടാകുന്നു.

ബൈറ്റ് തുകകളെ ഒരു ഈടാക്കിയ വ്യത്യാസമാക്കുക

മാനേജ്മെന്റ് ഇന്റർഫേസ് ക്ലൈന്റ് ഐഡിയും ഓരോ ദിശയിലുമുള്ള സഞ്ചിത ബൈറ്റ് തുകകളും വഹിക്കുന്ന ആനുകാലിക BYTECOUNT_CLI വരികൾ റിപ്പോർട്ട് ചെയ്യുന്നു, bytecount കമാൻഡ് അവ എത്ര ഇടവേളയിൽ വരുന്നു എന്ന് നിർണ്ണയിക്കുന്നു. സെർവറിന്റെ വീക്ഷണത്തിൽ, സ്വീകരിച്ച സംഖ്യ ക്ലൈന്റ് അയച്ച ബൈറ്റുകൾ കണക്കാക്കുന്നു, അയച്ച സംഖ്യ അതിന് എത്തിച്ച ബൈറ്റുകൾ കണക്കാക്കുന്നു. ലെഡ്ജറിന് ആഗിരണം ചെയ്യാനാകുന്ന ഇടവേളയിൽ സജ്ജമാക്കുക; വളരെ ചെറിയ ഇടവേള യഥാർത്ഥത്തിൽ ലഭിക്കാത്ത കൃത്യത വാങ്ങുന്നു.

ഒരു നിയന്ത്രണം മുഴുവൻ രൂപകൽപ്പനയും രൂപപ്പെടുത്തുന്നു: മാനേജ്മെന്റ് സോക്കറ്റ് ഒരു നിയന്ത്രണ കണക്ഷൻ മാത്രം സ്വീകരിക്കുന്നു. ഒരു മോണിറ്ററിംഗ് എക്സ്പോർട്ടർ, ഒരു GUI, നിങ്ങളുടെ കൺട്രോളർ എന്നിവയ്ക്ക് ഓരോന്നിനും സ്വന്തം തുറക്കാനാവില്ല. ഏത് പ്രോസസ് ചാനൽ സ്വന്തമാക്കുന്നു എന്ന് തീരുമാനിക്കുക, മറ്റുള്ളവ അതിൽ നിന്ന് അവസ്ഥ വായിക്കട്ടെ, കാരണം ഈ ഇന്റർഫേസ് ഭരണപരമായ പ്രവർത്തനങ്ങൾ നൽകുന്നു, എന്തായാലും ഹോസ്റ്റിന് പുറത്ത് അത് വെളിപ്പെടുത്തരുത്.

rx_delta = sample.rx_now - session.prev_rx
tx_delta = sample.tx_now - session.prev_tx
charge  = rx_delta + tx_delta
# same transaction:
ledger.total += charge
session.prev_rx, session.prev_tx = sample.rx_now, sample.tx_now

പുതിയ അടിസ്ഥാനരേഖകളും ഉപയോഗ വർദ്ധനവും ഒരുമിച്ച് പ്രതിബദ്ധമാക്കുക, അങ്ങനെ സാമ്പിൾ വീണ്ടും പ്ലേ ചെയ്യുമ്പോൾ രണ്ടുതവണ ഈടാക്കുന്നതിനു പകരം ഒന്നും ഈടാക്കില്ല. പിന്നോട്ട് നീങ്ങുന്ന കൗണ്ടർ ഒരു സൂചനയാണ്, കടമല്ല: സെഷൻ മാറ്റിസ്ഥാപിച്ചു അല്ലെങ്കിൽ ഡീമൺ പുനരാരംഭിച്ചു എന്നാണ് അർത്ഥം, ശരിയായ പ്രതികരണം നെഗറ്റീവ് തുക ക്രെഡിറ്റ് ചെയ്യുന്നതല്ല, സെഷൻ ഐഡന്റിറ്റി ഒത്തുതീർപ്പാക്കുകയാണ്.

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

തീരുന്നത് പ്രവേശനം നിഷേധിക്കട്ടെ, ടണൽ മാത്രം കൊല്ലരുത്

ഒരു അക്കൗണ്ട് അതിന്റെ പരിധിയിൽ എത്തുമ്പോൾ രണ്ട് കാര്യങ്ങൾ സംഭവിക്കണം: നിലവിലുള്ള സെഷനുകൾ അവസാനിക്കുന്നു, പുതിയവ നിരസിക്കപ്പെടുന്നു. മാനേജ്മെന്റ് പ്രോട്ടോക്കോൾ ക്ലൈന്റ് ഐഡി പ്രകാരം client-kill നൽകുന്നു, അത് അക്കൗണ്ടിന്റെ ഓരോ ജീവനുള്ള സെഷനും എണ്ണിയാൽ ആദ്യ പകുതി കൈകാര്യം ചെയ്യുന്നു, കണ്ണിൽപ്പെട്ട ഒരു വിലാസം കൊല്ലുന്നതിനു പകരം.

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

ടോക്കൺ അടിസ്ഥാനമാക്കിയ വീണ്ടും കണക്ഷനുകൾ സ്വന്തം പരീക്ഷണത്തിന് അർഹമാണ്. OpenVPN 2.6-ന് auth-gen-token ഉപയോഗിച്ച് സെഷൻ ടോക്കൺ ആന്തരികമായി സാധൂകരിക്കാനാകും, നിങ്ങളുടെ കൺട്രോളർ പരിധി നടപ്പാക്കാൻ ഉപയോഗിച്ചിരുന്ന ബാഹ്യ ആധികാരികതാ വിളി ഒഴിവാക്കി. അതിനാൽ ഇപ്പോഴും സാധുവായ ടോക്കൺ ഐഡന്റിറ്റി തെളിയിക്കുന്നു, ബാക്കിയുള്ള ക്വോട്ടയല്ല, പുതിയ ഓരോ ക്ലൈന്റ് ഇൻസ്റ്റൻസും ഇപ്പോഴും ലെഡ്ജറുമായി ആലോചിക്കണം. പകരം management-client-auth പ്രവർത്തനക്ഷമമാക്കിയാൽ, കൺട്രോളർ തന്നെ ആധികാരികതാകാരനാകുകയും സെഷൻ അവസ്ഥ വിശകലനം ചെയ്ത് കാലഹരണപ്പെട്ടതോ അസാധുവായതോ ആയ ടോക്കണുകൾ സ്വയം നിരസിക്കാനുള്ള ബാധ്യത പാരമ്പര്യമായി ഏൽക്കുകയും ചെയ്യുന്നു.

സാമ്പിളിംഗ് സൃഷ്ടിക്കുന്ന അധികപ്പെടൽ അംഗീകരിക്കുക

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

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

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