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 இயக்கினால், கட்டுப்படுத்தியே அங்கீகரிப்பவராகி, அமர்வு நிலையைத் தானே பகுப்பாய்வு செய்து காலாவதியான அல்லது செல்லாத டோக்கன்களைத் தானே மறுக்கும் கடமையை மரபாகப் பெறுகிறது.

மாதிரி எடுப்பு உருவாக்கும் மீறலை ஏற்றுக்கொள்ளுங்கள்

அவ்வப்போது கவனிப்பதும் துண்டிப்பதும் அறியப்பட்ட சகிப்புத்தன்மையுடன் மாதிரியிடப்பட்ட ஒதுக்கீட்டை உங்களுக்குத் தருகின்றன. ஒரு வாடிக்கையாளர் தோராயமாக ஒரு அறிக்கை இடைவெளியும் கட்டுப்படுத்தி செயல்பட எடுக்கும் நேரமும் சேர்த்து மீறலாம், ஒரு கணக்கில் ஒரே நேரத்தில் உள்ள அமர்வுகள் அந்தச் சாளரத்தைப் பல மடங்காக்குகின்றன. உங்களால் வழங்க முடியாத கடைசி பைட்டில் துல்லியமான வெட்டை விளம்பரப்படுத்துவதற்குப் பதிலாக அதை இடைமுகத்தில் சொல்லுங்கள்.

உண்மையான கடினமான உச்ச வரம்பு மற்றொரு பொறியியல் சிக்கல்: அனுப்பும் பாதையின் உள்ளே அமல்படுத்தல், அமர்வுகள் முழுவதும் அதே கணக்குடன் பிணைக்கப்பட்டது. கணக்கீடுகளை வேகமாகப் படிப்பது அதுவல்ல, மேலும் சுரங்கப்பாதைகளைத் திறக்கும் வாடிக்கையாளரை அது தாங்காது.

பயன்பாட்டுக்கு முன், எளிய செயலாக்கங்களை உடைக்கும் ஏற்பு நிகழ்வுகளை இயக்கவும்: மீண்டும் மீண்டும் மறுஇணைப்புகள், ஒரே நேரத்தில் இரண்டு சாதனங்கள், கட்டுப்படுத்தி மற்றும் நுழைவாயிலின் மறுதொடக்கம், இழந்த துண்டிப்பு நிகழ்வு, அமர்வின் நடுவில் கால மாற்றம், ஒதுக்கீடு தீர்ந்தவுடன் டோக்கன் மறுஇணைப்பு முயற்சி. பின்னர் கணக்கியல் இடையூறுகளுக்கான தோல்வி முறையை முடிவு செய்யுங்கள். நீடித்த கணக்கேடு நீங்கள் பதிவுசெய்த பயன்பாட்டைப் பாதுகாக்கிறது; ஒருபோதும் வராத கவனிப்புகளை அது உயிர்ப்பிக்க முடியாது, அந்த இரண்டு நிலைகளில் எதில் தான் இருக்கிறது என்பதை வாடிக்கையாளர் அறியத் தகுதியானவர்.