up اور down ہکس کے ساتھ OpenVPN کلائنٹ کا اپ ٹائم کیسے ناپیں

ایک ڈیش بورڈ پوچھتا ہے کہ کنکشن کتنی دیر سے فعال ہے، اور OpenVPN یہ فراہم نہیں کرتا۔ کلائنٹ جانتا ہے کہ اس کی سرنگ کب اوپر آئی، لیکن صرف اسی صورت میں جب کوئی سیشن کی حالت ضائع ہونے سے پہلے وہ لمحہ ریکارڈ کرے۔ معاون جگہ up ہک ہے، اور محفوظ کرنے کے قابل قدر فارمیٹ شدہ سٹرنگ نہیں بلکہ خام epoch سیکنڈ ہے۔ اس کے بعد سب حساب ہے، ساتھ کچھ ترتیب کے قواعد جو فیصلہ کرتے ہیں کہ عدد دیانتدار رہتا ہے یا نہیں۔

یقینی بنائیں کہ ہک واقعی چلتے ہیں

اس کے گرد کچھ بھی ڈیزائن کرنے سے پہلے ثابت کریں کہ ہک چلتا ہے۔ کم سے کم کلائنٹ ترتیب کو script-security 2 اور واضح راستے up اور down درکار ہیں؛ حفاظتی لائن کے بغیر OpenVPN اسکرپٹ چلانے سے انکار کرتا ہے اور یہ صاف کہتا ہے۔ اسی وقت up-restart اور down-pre شامل کریں تاکہ دوبارہ آغاز اور انہدام کے راستے متوقع طریقے سے برتاؤ کریں۔

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

دیکھیں کہ ہک کس صارف کے طور پر چلتا ہے۔ user اور group مقرر ہونے پر OpenVPN اسکرپٹ چلانے سے پہلے مراعات چھوڑ دیتا ہے، اس لیے جس ڈائریکٹری میں root لکھ سکتا ہے وہ ہک کے لیے بند ہو سکتی ہے۔ راستہ اپنے شیل کے بجائے سروس کے نقطہ نظر سے چنیں۔

ایک epoch قدر ریکارڈ کریں اور اسے جان بوجھ کر مٹا دیں

up ہک کو ایک لائن درکار ہے، date +%s > /run/openvpn-client.started, ہر مثال کے لیے راستہ ایڈجسٹ کر کے۔ epoch قدر بعد میں زبان، منطقہ وقت اور فارمیٹ کے سوالات سے بچاتی ہے، اور یہ وہی عدد ہے جسے نگرانی کا ایجنٹ اپنی گھڑی سے موازنہ کر سکتا ہے۔

مٹانا لکھنے جتنا ہی اہم ہے۔ down ہک کو فائل خالی کرنی چاہیے یا ہٹانی چاہیے، اور down-pre یہ انٹرفیس بند ہونے سے پہلے کرتا ہے، جس سے وہ کھڑکی ختم ہو جاتی ہے جہاں فائل ایسی سرنگ بیان کرتی ہے جو پہلے ہی جا چکی ہے۔ up-restart پھر اندرونی دوبارہ آغاز پر ٹکڑا تازہ کرتا ہے، اصل قدر کو اس کی جگہ چھوڑنے کے بجائے۔ اس جوڑ کے بغیر ping کی مدت ختم ہونے کے بعد دوبارہ آغاز ایسا عدد دیتا ہے جو سرنگ کے دوبارہ قائم ہونے کے دوران بڑھتا رہتا ہے۔

درست عمر والی جگہ چنیں۔ /run کے نیچے کی فائل ری بوٹ پر غائب ہو جاتی ہے، جو حقیقت سے مطابقت رکھتی ہے، جبکہ /tmp کے نیچے کی فائل غیر متوقع طور پر صاف ہو سکتی ہے اور ترتیب کی ڈائریکٹری والی فائل گمراہ کن انداز میں باقی رہتی ہے۔ اجازتیں ایسی مقرر کریں کہ صرف سروس صارف اور نگرانی کا قاری اسے پڑھ سکے۔

لاگ لائنوں پر بھروسہ کیے بغیر اپ ٹائم شمار کریں

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

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

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

دوبارہ کنکشن، دوبارہ آغاز اور متعدد مثالیں شامل کریں

ایک میزبان پر دو سرنگوں کو دو فائلیں درکار ہیں، کلید وہ مثال نام جو سروس پہلے ہی استعمال کرتی ہے۔ مشترکہ راستہ یعنی تازہ ترین کنکشن ہر پروفائل کے آغاز کا وقت اوپر لکھ دیتا ہے، اور علامت وہ عدد ہے جو دوسری سرنگ شروع ہونے پر پیچھے چھلانگ لگاتا ہے۔

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

سرور کی طرف، حالت کی فائل ہر کلائنٹ کے لیے connected-since قدر رکھتی ہے، جو ایک اور سوال کا جواب دیتی ہے: سرور نے اس ساتھی کو آخری بار کب دیکھا۔ اسے متبادل کے بجائے کراس چیک کے لیے استعمال کریں، کیونکہ یہ اس سیشن کے ساتھ غائب ہو جاتی ہے جس کی وہ وضاحت کرتی ہے۔ دونوں میں سے کوئی پیمائش سرنگ کے پیچھے کی ایپلیکیشن کی صحت کے بارے میں کچھ نہیں کہتی۔

ترتیب کی غلطیاں پکڑنے والی تین جانچیں چلائیں

عام کنکشن، جبری دوبارہ کنکشن اور صاف توقف کی جانچ کریں، ہر ایک کے بعد انٹرفیس فہرست اور فائل اکٹھے پڑھیں۔ صاف توقف کے بعد بھی موجود ٹکڑا، یا ایسی سرنگ کا دعویٰ کرنے والی فائل جو انٹرفیس فہرست میں نہ ہو، سیدھا ہک ترتیب کی طرف اشارہ کرتی ہے۔ جانچیں سروس صارف کے طور پر اور سروس کے راستوں کے ساتھ چلائیں، کیونکہ root شیل دوسری فائل دیکھ کر پراعتماد غلط جواب دے سکتا ہے۔ پھر سست پولر کو فائل پڑھنے دیں اور یقینی بنائیں کہ وہ کبھی اس میں نہیں لکھتا۔

ہر ساٹھ سیکنڈ بعد ایک پول انتباہات کا احاطہ کرتا ہے، اور کسی ہک کو یہ نہیں ماننا چاہیے کہ وہ پولر زندہ ہے۔ یہ دونوں ذمہ داریاں الگ رکھیں اور کوئی بھی فریق دوبارہ تعینات ہو تو عدد قابل اعتماد رہتا ہے۔