Որտեղ է պատկանում ամսական տվյալների քվոտան 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

Նոր բազային գծերն ու օգտագործման աճը ամրագրեք միասին, որպեսզի նմուշի կրկնությունը ոչինչ չգանձի՝ կրկնակի գանձելու փոխարեն։ Հետ շարժվող հաշվիչը ազդանշան է, ոչ պարտք. դա նշանակում է, որ նստաշրջանը փոխարինվել է կամ դեմոնը վերագործարկվել է, և ճիշտ պատասխանը նստաշրջանի ինքնությունը հաշտեցնելն է, այլ ոչ թե բացասական գումար մուտքագրելը։

Անջատման ուղին նույն խնամքն է պահանջում։ Եթե վերջնական իրադարձությունը կրում է նստաշրջանի ավարտի գումարներ, գանձեք միայն տարբերությունը վերջին ամրագրված նմուշից։ Ամբողջ գումարը ավելացնելը այն բանից հետո, երբ պարբերական նմուշառումն արդեն գանձվել է, տնական քվոտային համակարգերում ամենատարածված կրկնակի հաշվարկն է։ Ժամանակահատվածի սահմանը հատող նստաշրջաններին նույնպես կանոն է պետք, քանի որ մեկ վերջնական գումարը տեղեկություն չի կրում այն մասին, թե երբ են բայթերը հատել կեսգիշերը։

Սպառումը թող մերժի մուտքը, ոչ միայն սպանի թունելը

Երբ հաշիվը հասնում է իր սահմանին, երկու բան պետք է տեղի ունենա. գոյություն ունեցող նստաշրջաններն ավարտվեն, և նորերը մերժվեն։ Կառավարման արձանագրությունը տրամադրում է client-kill՝ ըստ հաճախորդի ID-ի, ինչը լուծում է առաջին կեսը, քանի դեռ թվարկում եք հաշվի յուրաքանչյուր կենդանի նստաշրջան՝ պատահաբար նկատած մեկ հասցեն սպանելու փոխարեն։

Երկրորդ կեսն այն է, որտեղ քվոտային ձևավորումները ձախողվում են։ Միայն սպանելը մրցավազք է հաճախորդի վերակապակցման հանգույցի հետ, որը հաճույքով կվերադառնա վայրկյաններ անց։ Մուտքը պետք է խորհրդակցի համատեղ մատյանի հետ, և բազմադարպաս տեղակայման դեպքում այդ ստուգումը չի կարող լինել մեքենայական ֆայլ։ Յուրաքանչյուր օրինակ, որը կարող է ընդունել մուտք, պետք է տեսնի նույն սպառված վիճակը։

Նշանների վրա հիմնված վերակապակցումները արժանի են իրենց սեփական փորձությանը։ OpenVPN 2.6-ը կարող է ներքուստ վավերացնել նստաշրջանի նշանը auth-gen-token-ով՝ շրջանցելով արտաքին նույնականացման կանչը, որը ձեր կարգավորիչն օգտագործում էր սահմանը կիրառելու համար։ Այսպիսով, դեռ վավեր նշանը ապացուցում է ինքնությունը, ոչ թե մնացած քվոտան, և յուրաքանչյուր նոր հաճախորդի օրինակ դեռ պետք է խորհրդակցի մատյանի հետ։ Եթե փոխարենը միացնեք management-client-auth-ը, կարգավորիչը դառնում է նույնականացնող և ժառանգում է նստաշրջանի վիճակը վերլուծելու և ժամկետանց կամ անվավեր նշանները ինքնուրույն մերժելու պարտականությունը։

Ընդունեք այն գերազանցումը, որը ստեղծում է նմուշառումը

Պարբերական դիտարկումը գումարած անջատումը ձեզ տալիս են հայտնի հանդուրժողականությամբ նմուշառված քվոտա։ Հաճախորդը կարող է գերազանցել մոտավորապես մեկ հաշվետվության ընդմիջումով գումարած այն ժամանակով, որն անհրաժեշտ է կարգավորիչին գործելու համար, և մեկ հաշվի միաժամանակյա նստաշրջանները բազմապատկում են այդ պատուհանը։ Ասացեք դա միջերեսում՝ վերջին բայթի ճշգրիտ կտրվածք գովազդելու փոխարեն, որը չեք կարող ապահովել։

Իսկական կոշտ առաստաղը այլ ինժեներական խնդիր է. կիրառում փոխանցման ուղու ներսում՝ կապված նույն հաշվի հետ նստաշրջանների ընթացքում։ Հաշվիչներն ավելի արագ կարդալը նույնը չէ, և այն չի դիմանում հաճախորդին, որը պարզապես ավելի շատ թունելներ է բացում։

Տեղակայումից առաջ գործարկեք ընդունման այն դեպքերը, որոնք կոտրում են միամիտ իրականացումները. կրկնվող վերակապակցումներ, երկու սարք միաժամանակ, կարգավորիչի և դարպասի վերագործարկումներ, կորցրած անջատման իրադարձություն, ժամանակահատվածի պտտում նստաշրջանի կեսին և նշանով վերակապակցման փորձ սպառումից անմիջապես հետո։ Ապա որոշեք հաշվառման ընդհատումների ձախողման ռեժիմը։ Կայուն մատյանը պաշտպանում է ձեր գրանցած օգտագործումը. այն չի կարող հարություն տալ դիտարկումներին, որոնք երբեք չեն հասել, և հաճախորդն արժանի է իմանալու, թե այդ երկու իրավիճակներից որում է գտնվում։