OpenVPN એકાઉન્ટ દીઠ માસિક ડેટા ક્વોટા ક્યાં આવે છે

ટનલ દર વખતે ફરી જોડાય ત્યારે રીસેટ થતો ક્વોટા મર્યાદા નથી, અને ટકાઉ સ્થિતિ રાખવાની જગ્યા વગર VPN સર્વર પર બાઇટ કાઉન્ટર જોડી દેવામાં આવે ત્યારે બરાબર એ જ મળે છે. કાઉન્ટર સત્રનું છે; ક્વોટા વ્યક્તિનું કે ઉપકરણ કરારનું છે. આ સુવિધાની બધી મુશ્કેલી એ જ અસંગતિમાંથી આવે છે, તેથી નીચેની ચકાસણીઓ સ્થિતિ ક્યાં રહે છે અને કયા સ્તરને નિર્ણય લેવાની પરવાનગી છે તે વિશે છે.

ક્વોટા ટનલ સાથે નહીં, એકાઉન્ટ સાથે બાંધો

ક્વોટાનો વિષય નામ આપીને શરૂ કરો. એક વ્યક્તિ પાસે ત્રણ ઉપકરણ પ્રમાણપત્રો હોઈ શકે, અને તે અલગથી પ્રમાણીકરણ કરે છે એટલા માટે તેમાંથી કોઈને સ્વતંત્ર માસિક બજેટ મળવું જોઈએ નહીં. ફરી જોડાણ, નવા ટનલ સરનામાં અને બીજા ગેટવે તરફ સ્થળાંતર સહન કરતું સ્થિર એકાઉન્ટ ઓળખકર્તા એ જ એકમાત્ર એન્કર છે જેનો ક્વોટા ઉપયોગ કરી શકે. પ્રમાણપત્રનું સામાન્ય નામ એ ચાવી તરીકે ત્યારે જ કામ કરે છે જ્યારે તમારી જારી નીતિ નામ દીઠ એક એકાઉન્ટની ખાતરી આપે.

સોંપાયેલ ટનલ સરનામું ક્યારેય જવાબ નથી. સરનામાં ફરી વપરાય છે, પૂલ વહેંચાય છે, અને એ જ એકાઉન્ટ એક જ મિનિટમાં બે ગેટવે પર બે વાર દેખાઈ શકે. જો ખાતાવહી સરનામા પર આધારિત હોય, તો ટાંકી ફરી ભરવા માટે ડિસ્કનેક્ટ અને ફરી કનેક્ટ થવું પૂરતું છે.

ગણતરી ઓડિટપાત્ર બનાવવા માટે દરેક સત્ર દીઠ પૂરતું નોંધો: એકાઉન્ટ, બિલિંગ સમયગાળો, ગેટવે ઇન્સ્ટન્સ, સત્ર ઓળખ, છેલ્લે નિરીક્ષિત કાઉન્ટર અને નિશ્ચિત કુલ. સત્ર ઓળખમાં ડિમન શરૂઆતની પેઢી સામેલ કરો, કારણ કે ફરી શરૂ થયેલ સર્વર ક્લાઇન્ટ ID ફરી વાપરે છે અને સાદું મેળ બેસાડવું અગાઉની આધારરેખા વારસામાં લઈ લે.

એકમ, દિશા અને રીસેટ સીમા નક્કી કરો

કોઈપણ સંગ્રહ શરૂ થાય તે પહેલાં ચાર વ્યાખ્યાઓ લેખિતમાં નક્કી કરવી પડશે. ક્વોટા ક્લાઇન્ટ મોકલે તે બાઇટ ગણે છે, તે મેળવે તે બાઇટ ગણે છે, કે બંનેનો સરવાળો? એક ગીગાબાઇટ 10^9 બાઇટ છે કે 2^30? કઈ સ્થાનિક કલાકે અને કયા સમય ક્ષેત્રમાં સમયગાળો ફરે છે? અને કાઉન્ટર બરાબર શું માપે છે, જ્યારે ટનલ ઓવરહેડ અને ફરી પ્રસારણ સામેલ છે પણ એપ્લિકેશન ફાઇલનું કદ અને પ્રદાતાનું બિલ નથી?

આમાંથી કોઈ પસંદગી ખોટી નથી, પણ અમલીકરણ અને ગ્રાહક સમક્ષનો આંકડો મેળ ખાવા જોઈએ. એક જ સિસ્ટમના બે અર્ધા GiB અથવા સ્થાનિક સમયને બદલે UTC મધ્યરાત્રિએ થતા ફેરફાર વિશે અસહમત હોય તો બરાબર એ જ પ્રકારની ટિકિટ બને છે જે સમગ્ર ક્વોટા પ્રત્યેનો વિશ્વાસ ઘટાડે છે.

બાઇટ કુલને એક ગણાયેલા તફાવતમાં ફેરવો

મેનેજમેન્ટ ઇન્ટરફેસ સામયિક BYTECOUNT_CLI લીટીઓની જાણ કરે છે જે ક્લાઇન્ટ ID અને દરેક દિશામાં સંચિત બાઇટ કુલ ધરાવે છે, અને 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

નવી આધારરેખાઓ અને વપરાશ વધારો સાથે નિશ્ચિત કરો, જેથી નમૂનો ફરી ચલાવવાથી બે વાર ગણવાને બદલે કંઈ ગણાય નહીં. પાછળ જતું કાઉન્ટર સંકેત છે, દેવું નથી: તેનો અર્થ છે કે સત્ર બદલાયું છે અથવા ડિમન ફરી શરૂ થયું છે, અને સાચો પ્રતિભાવ એ છે કે નકારાત્મક રકમ જમા કરવાને બદલે સત્ર ઓળખ મેળવવી.

ડિસ્કનેક્શન માર્ગને પણ એ જ કાળજી જોઈએ. જો અંતિમ ઘટના સત્ર-અંતના કુલ ધરાવે, તો ફક્ત છેલ્લા નિશ્ચિત નમૂના કરતાં તફાવત ગણો. સામયિક નમૂનાઓ પહેલેથી ગણાઈ ગયા પછી આખું કુલ ઉમેરવું એ ઘરગથ્થુ ક્વોટા સિસ્ટમમાં સૌથી સામાન્ય બેવડી ગણતરી છે. સમયગાળાની સીમા ઓળંગતા સત્રો માટે પણ નિયમ જોઈએ, કારણ કે એક અંતિમ કુલ બાઇટ ક્યારે મધ્યરાત્રિ પાર કર્યા તેની કોઈ માહિતી ધરાવતું નથી.

ખતમ થવાથી પ્રવેશ નકારાય, ફક્ત ટનલ ન મરે

જ્યારે એકાઉન્ટ તેની મર્યાદા પર પહોંચે, બે વસ્તુ થવી જોઈએ: હાલનાં સત્રો પૂરાં થાય અને નવાં નકારાય. મેનેજમેન્ટ પ્રોટોકોલ ક્લાઇન્ટ ID દ્વારા client-kill આપે છે, જે પહેલો અર્ધો ભાગ ત્યારે જ સંભાળે છે જ્યારે તમે એકાઉન્ટનાં દરેક જીવંત સત્રની ગણતરી કરો, બસ એક જ સરનામું મારવાને બદલે જે તમારી નજરે પડ્યું.

બીજો અર્ધો ભાગ એ છે જ્યાં ક્વોટા રચનાઓ નિષ્ફળ જાય છે. ફક્ત મારવું એ ક્લાઇન્ટના ફરી જોડાણના લૂપ સામેની દોડ છે, જે સેકન્ડો પછી ખુશીથી પાછું આવશે. પ્રવેશે વહેંચાયેલી ખાતાવહી સાથે પરામર્શ કરવો પડે, અને બહુ-ગેટવે જમાવટમાં એ ચકાસણી મશીન દીઠ ફાઇલ ન હોઈ શકે. લોગિન સ્વીકારી શકે તેવા દરેક ઇન્સ્ટન્સે એ જ ખતમ થયેલી સ્થિતિ જોવી જોઈએ.

ટોકન આધારિત ફરી જોડાણ પોતાની કસોટીને લાયક છે. OpenVPN 2.6 auth-gen-token સાથે સત્ર ટોકનની આંતરિક ચકાસણી કરી શકે છે, અને તમારું નિયંત્રક મર્યાદા લાગુ કરવા માટે વાપરતું બાહ્ય પ્રમાણીકરણ કૉલ છોડી દે છે. તેથી હજી માન્ય ટોકન ઓળખ સાબિત કરે છે, બાકી ક્વોટા નહીં, અને દરેક નવા ક્લાઇન્ટ ઇન્સ્ટન્સે હજી પણ ખાતાવહી સાથે પરામર્શ કરવો પડે. જો તમે તેના બદલે management-client-auth ચાલુ કરો, તો નિયંત્રક પ્રમાણીકર્તા બની જાય છે અને સત્ર સ્થિતિનું વિશ્લેષણ કરીને સમાપ્ત કે અમાન્ય ટોકન જાતે નકારવાની જવાબદારી વારસામાં લે છે.

નમૂનાકરણ જે વધારો કરે તે સ્વીકારો

સામયિક નિરીક્ષણ અને ડિસ્કનેક્શન તમને જાણીતી સહિષ્ણુતા સાથે નમૂનાકૃત ક્વોટા આપે છે. ક્લાઇન્ટ આશરે એક અહેવાલ અંતરાલ અને નિયંત્રકને કાર્ય કરવા લાગતો સમય એટલો વધારે જઈ શકે છે, અને એક એકાઉન્ટ પર સમવર્તી સત્રો એ વિંડોને ગણી ગણી વધારે છે. છેલ્લા બાઇટ પર ચોક્કસ કટઑફની જાહેરાત કરવાને બદલે, જે તમે આપી શકતા નથી, તે ઇન્ટરફેસમાં કહો.

ખરેખર કઠણ ટોપી એ બીજી ઇજનેરી સમસ્યા છે: ફોરવર્ડિંગ માર્ગની અંદર અમલ, સત્રો દરમિયાન એ જ એકાઉન્ટ સાથે બંધાયેલો. કાઉન્ટર ઝડપથી વાંચવું એ જ વસ્તુ નથી, અને ફક્ત વધુ ટનલ ખોલતા ક્લાઇન્ટ સામે તે ટકતું નથી.

જમાવટ પહેલાં એ સ્વીકૃતિ કેસ ચલાવો જે સાદા અમલીકરણોને તોડે છે: વારંવાર ફરી જોડાણ, એકસાથે બે ઉપકરણ, નિયંત્રક અને ગેટવેના પુનઃપ્રારંભ, ખોવાયેલી ડિસ્કનેક્શન ઘટના, સત્રની વચ્ચે સમયગાળો બદલાવો, અને ખતમ થયાના તરત પછી ટોકન દ્વારા ફરી જોડાણનો પ્રયાસ. પછી હિસાબી વિક્ષેપો માટે નિષ્ફળતાનો મોડ નક્કી કરો. ટકાઉ ખાતાવહી તમે નોંધેલા વપરાશને રક્ષે છે; જે નિરીક્ષણો ક્યારેય આવ્યાં જ નથી તેને તે પુનર્જીવિત કરી શકતું નથી, અને ગ્રાહક એ જાણવાને પાત્ર છે કે તે આ બેમાંથી કઈ સ્થિતિમાં છે.