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

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

الٹی ترتیب میں باہر کی طرف جائیں: پہلے صارفین، پھر پراکسی، پھر ٹنل — ہر ایک کو وہی جزو روکتا ہے جس نے اسے شروع کیا۔

کچھ بھی بند کرنے سے پہلے یونٹس کی فہرست بنائیں

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

نام کمزور ثبوت ہیں۔ صارف کی پراکسی، سسٹم کی پراکسی اور کسی دوسرے اکاؤنٹ کی ٹنل ایک ہی نام رکھ سکتی ہیں مگر بالکل غیر متعلق زندگی کے چکر رکھتی ہیں۔

پہلے کام مکمل کریں، پھر صارف کو روکیں

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

بندش کے دوران پرواز میں رہنے والی درخواستیں ریکارڈ کا حصہ ہیں، کیونکہ اگلی بار چلنے پر دوبارہ کوششوں کا طوفان وہیں سے آتا ہے۔

ExecStop اور ExecStopPost مختلف اوزار ہیں

ExecStop= — یہ ہم وقت بندش کا عمل ہے؛ ExecStopPost= — یہ صفائی ہے جو ناکام آغاز کے بعد بھی چلتی ہے۔ ایسا بندش کا حکم جو صرف عمل کو سگنل بھیج کر واپس آ جاتا ہے، systemd کو آگے بڑھنے دیتا ہے جبکہ صارف ابھی ڈیٹا بہا رہا ہوتا ہے۔ ہر وہ چیز جو بہرحال ہونی چاہیے بعد والی شکل سے تعلق رکھتی ہے، اور ہر وہ چیز جو بندش کو روکنی چاہیے ہم وقت شکل سے۔ موثر یونٹ اور اس کی drop-in فائلیں دیکھیں بجائے اس کے کہ پیکج کی فائل کو اسی جگہ ترمیم کریں۔

انحصار کا گراف بندش کے کاموں کو ترتیب دیتا ہے۔ یہ غیر ہم وقت اسکرپٹ کو ہم وقت نہیں بناتا، اور نہ دور دراز کی ایپلیکیشن کو اس کا ڈیٹا محفوظ کرنے پر مجبور کرتا ہے۔

بندش کو محدود کریں اور جانیں کہ اس حد کی کیا قیمت ہے

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

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

مالک کے ذریعے منقطع کریں، پھر تین صورتیں جانچیں

جب صارفین نیچے آ جائیں تو ٹنل رکھنے والے مینیجر سے کہیں کہ منقطع ہو: systemd کی مثال، NetworkManager کا فعال کنکشن یا وینڈر کی سروس۔ کسی غیر متعلق OpenVPN عمل کو قتل کرنا ضروری نہیں کہ وہ سیشن ہٹا دے جس نے راستہ دیا تھا، اور ری اسٹارٹ پالیسی والی پراکسی راستہ کھولتے وقت درخواست دوبارہ بنا سکتی ہے۔ اس پالیسی کو شروع کرنے سے پہلے منصوبہ بند بندش کے ساتھ ہم آہنگ کریں۔

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