سهمیه ماهانه داده برای هر حساب OpenVPN کجا قرار میگیرد
سهمیهای که با هر اتصال دوباره بازنشانی میشود محدودیت نیست. مصرف را به ازای هر حساب پیگیری کنید، هر اختلاف بایت را یک بار محاسبه کنید و کاری کنید که اتمام سهمیه ورود را مسدود کند.
سهمیهای که هر بار با اتصال دوباره تونل بازنشانی میشود محدودیت نیست، و این دقیقاً همان چیزی است که وقتی یک شمارنده بایت بدون جایی برای نگهداشتن حالت پایدار به یک سرور VPN پیچ میشود به دست میآید. شمارنده به یک نشست تعلق دارد؛ سهمیه به یک شخص یا یک قرارداد دستگاه تعلق دارد. تمام دشواری این قابلیت از همین ناسازگاری میآید، بنابراین بررسیهای زیر درباره این است که حالت کجا زندگی میکند و کدام لایه اجازه تصمیمگیری دارد.
سهمیه را به حساب گره بزنید، نه به تونل
با نامگذاری موضوع سهمیه شروع کنید. یک شخص ممکن است سه گواهی دستگاه داشته باشد، و هیچیک از آنها نباید فقط به این دلیل که جداگانه احراز هویت میکنند بودجه ماهانه مستقل بگیرد. شناسه حساب پایداری که از اتصالهای دوباره، نشانیهای جدید تونل و جابهجایی به درگاه دوم جان سالم به در میبرد تنها لنگرگاهی است که سهمیه میتواند از آن استفاده کند. نام مشترک گواهی تنها زمانی بهعنوان این کلید کار میکند که سیاست صدور شما یک حساب به ازای هر نام را تضمین کند.
نشانی تونل تخصیصیافته هرگز پاسخ نیست. نشانیها بازیافت میشوند، استخرها مشترکاند، و همان حساب میتواند در همان دقیقه دو بار روی دو درگاه ظاهر شود. اگر دفتر کل بر پایه نشانی باشد، قطع و وصل شدن دوباره برای پر کردن دوباره مخزن کافی است.
برای هر نشست به اندازهای ثبت کنید که حسابداری قابل حسابرسی باشد: حساب، دوره صورتحساب، نمونه درگاه، هویت نشست، آخرین شمارندههای مشاهدهشده و مجموع تثبیتشده. نسل آغاز سرویسدهنده را در هویت نشست بگنجانید، زیرا سرور راهاندازیشده مجدداً از شناسههای کارخواه استفاده میکند و یک تطبیق سادهلوحانه خط پایه قبلی را به ارث میبرد.
واحد، جهت و مرز بازنشانی را تثبیت کنید
پیش از شروع هر گردآوری باید چهار تعریف بهصورت مکتوب روشن شود. آیا سهمیه بایتهایی را میشمارد که کارخواه میفرستد، بایتهایی را که دریافت میکند، یا مجموع هر دو را؟ آیا یک گیگابایت 10^9 بایت است یا 2^30؟ در چه ساعتی به وقت محلی و در کدام منطقه زمانی دوره عوض میشود؟ و شمارنده دقیقاً چه چیزی را میسنجد، با توجه به اینکه سرباری تونل و ارسالهای دوباره در آن گنجانده شدهاند اما اندازه فایل برنامه و صورتحساب ارائهدهنده نه؟
هیچیک از این انتخابها غلط نیست، اما پیادهسازی و عددی که مشتری میبیند باید همخوان باشند. دو نیمه از یک سامانه که بر سر GiB یا بر سر تغییری که در نیمهشب UTC بهجای وقت محلی رخ میدهد اختلاف دارند، دقیقاً همان بلیتی را تولید میکنند که اعتماد به کل سهمیه را فرسوده میکند.
مجموع بایتها را به یک اختلاف حسابشده تبدیل کنید
رابط مدیریت خطوط دورهای BYTECOUNT_CLI را گزارش میکند که شناسه کارخواه بههمراه مجموعهای انباشته بایت در هر جهت را حمل میکنند، و فرمان bytecount تعیین میکند که این خطوط هر چند وقت برسند. از دید سرور، رقم دریافتی بایتهایی را میشمارد که کارخواه فرستاده و رقم ارسالی بایتهای تحویلشده به آن را میشمارد. فاصله را روی چیزی بگذارید که دفتر کل بتواند هضم کند؛ فاصله بسیار کوتاه دقتی را میخرد که در واقع به دست نمیآورید.
یک محدودیت کل طراحی را شکل میدهد: سوکت مدیریت تنها یک اتصال کنترل را میپذیرد. یک صادرکننده پایش، یک رابط گرافیکی و کنترلکننده شما نمیتوانند هر یک اتصال خودشان را باز کنند. تصمیم بگیرید کدام فرایند مالک کانال است و بگذارید بقیه حالت را از آن بخوانند، زیرا این رابط اقدامهای مدیریتی میدهد و بههرحال نباید بیرون از میزبان افشا شود.
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 را فعال کنید، کنترلکننده خودش احرازکننده میشود و وظیفه تجزیه حالت نشست و رد توکنهای منقضی یا نامعتبر را به ارث میبرد.
بیشرویی را که نمونهگیری ایجاد میکند بپذیرید
مشاهده دورهای بههمراه قطع اتصال به شما سهمیهای نمونهبرداریشده با رواداری معلوم میدهد. کارخواه میتواند تقریباً به اندازه یک فاصله گزارش بهعلاوه زمانی که کنترلکننده برای اقدام لازم دارد بیشروی کند، و نشستهای همزمان روی یک حساب آن پنجره را چند برابر میکنند. این را در رابط بگویید، بهجای تبلیغ یک قطع دقیق در آخرین بایت که نمیتوانید ارائه دهید.
سقف سخت واقعی مسئله مهندسی دیگری است: اعمال درون مسیر ارسال، گرهخورده به همان حساب در سراسر نشستها. خواندن سریعتر شمارندهها همان چیز نیست، و در برابر کارخواهی که صرفاً تونلهای بیشتری باز میکند دوام نمیآورد.
پیش از عرضه، موارد پذیرشی را اجرا کنید که پیادهسازیهای سادهلوحانه را میشکنند: اتصالهای دوباره مکرر، دو دستگاه همزمان، راهاندازی دوباره کنترلکننده و درگاه، رویداد قطع اتصال گمشده، تغییر دوره در میانه نشست، و تلاش برای اتصال دوباره با توکن درست پس از اتمام سهمیه. سپس حالت شکست برای وقفههای حسابداری را تعیین کنید. دفتر کل پایدار مصرفی را که ثبت کردهاید محافظت میکند؛ نمیتواند مشاهداتی را که هرگز نرسیدهاند زنده کند، و مشتری سزاوار است بداند در کدامیک از این دو وضعیت است.