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 فعال کریں تو کنٹرولر خود تصدیق کنندہ بن جاتا ہے اور سیشن کی حالت کا تجزیہ کر کے میعاد ختم یا غلط ٹوکن خود رد کرنے کی ذمہ داری ورثے میں لیتا ہے۔

نمونہ لینے سے پیدا ہونے والی زیادتی قبول کریں

وقفے وقفے کی نگرانی اور منقطع ہونا آپ کو معلوم رواداری کے ساتھ نمونہ شدہ کوٹہ دیتے ہیں۔ کلائنٹ تقریباً ایک رپورٹنگ وقفہ اور کنٹرولر کو کارروائی کے لیے درکار وقت کے برابر زیادہ جا سکتا ہے، اور ایک اکاؤنٹ پر بیک وقت سیشن اس کھڑکی کو کئی گنا کر دیتے ہیں۔ آخری بائٹ پر درست کٹائی کی تشہیر کرنے کے بجائے یہ انٹرفیس میں بتائیں، جو آپ فراہم نہیں کر سکتے۔

اصل سخت چھت ایک اور انجینئرنگ مسئلہ ہے: فارورڈنگ راستے کے اندر نفاذ، سیشنوں میں اسی اکاؤنٹ سے بندھا ہوا۔ کاؤنٹر تیزی سے پڑھنا وہی چیز نہیں، اور یہ صرف زیادہ سرنگیں کھولنے والے کلائنٹ کے سامنے نہیں ٹکتا۔

تعیناتی سے پہلے وہ قبولیتی کیس چلائیں جو سادہ عمل درآمد توڑتے ہیں: بار بار دوبارہ رابطے، ایک ساتھ دو ڈیوائس، کنٹرولر اور گیٹ وے کی دوبارہ شروعات، گم شدہ منقطع ہونے کا واقعہ، سیشن کے وسط میں مدت کا پلٹنا، اور کوٹہ ختم ہونے کے فوراً بعد ٹوکن سے دوبارہ رابطے کی کوشش۔ پھر حساب کتاب کی رکاوٹوں کے لیے ناکامی کا طریقہ طے کریں۔ پائیدار کھاتہ آپ کے درج کردہ استعمال کی حفاظت کرتا ہے؛ یہ کبھی نہ آنے والے مشاہدوں کو زندہ نہیں کر سکتا، اور گاہک یہ جاننے کا حقدار ہے کہ وہ ان دو حالتوں میں سے کس میں ہے۔