آپ کا OpenVPN کلائنٹ ایک بار وقت گزرنے کے بعد کیوں بند رہتا ہے

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

اس سے شروع کریں جو یونٹ نے واقعی کیا، اس سے نہیں جو مانیٹرنگ کا دعویٰ ہے۔ systemctl status openvpn-client@office اور journalctl -u openvpn-client@office -n 50 باہر نکلنے کی وجہ اور وہ آخری سطر دکھاتے ہیں جو کلائنٹ نے جانے سے پہلے لکھی۔

عمل کسی کے دیکھنے سے پہلے باہر نکل گیا

بغیر خرابی کے غائب ہونے والا کلائنٹ عام طور پر جان بوجھ کر باہر نکلا ہوتا ہے۔ یہ رویہ پروفائل طے کرتا ہے، سروس مینیجر نہیں: ping-exit سامنے والے فریق کے جواب دینا بند کرتے ہی عمل ختم کر دیتا ہے، جبکہ ping-restart عمل کو رکھتا ہے اور اس کے اندر دوبارہ جڑتا ہے۔ سیشن کی حدیں اور غیر فعالیت کے ٹائمر باہر سے وہی تصویر بناتے ہیں: نہ سرنگ اور نہ الارم۔

دو ping ہدایات ایک ہی پروفائل میں اکٹھی نہیں ہو سکتیں، اس لیے ایک منتخب کریں اور انتخاب درج کریں۔ سرور کو بھی دیکھیں، کیونکہ اس کا اپنا ping-exit کلائنٹ کی درخواست سے قطع نظر سیشن بند کر دیتا ہے، اور وہ فیصلہ کس نے لیا یہ صرف سرور لاگ میں درج ہوتا ہے۔

ping-exit اور ping-restart کے درمیان انتخاب

خود صحت یاب ہونے والے لیپ ٹاپ یا دور دراز مقام کے لیے ping-restart منتخب کریں، اور ایسے مواقع کے لیے ping-exit رکھیں جہاں مردہ سرنگ کو عمل روکنا ہو تاکہ کوئی اور اس پر کارروائی کر سکے۔ اعداد و تعلق سے کم اہم ہیں: ping 10 کے ساتھ ping-restart 60 کا مطلب ہے جانچ سے پہلے دس سیکنڈ کی خاموشی اور دوبارہ شروع ہونے سے پہلے ساٹھ، جو نقصان والے موبائل لنک پر جارحانہ اور تار والے پر معقول ہے۔ وجہ سطر کے ساتھ لکھیں، ورنہ اگلا قاری سمجھے گا کہ ڈیفالٹ اقدار جان بوجھ کر تھیں۔

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

ایسی نگرانی جو یونٹ کو واقعی دوبارہ شروع کرے

systemd میزبان پر سب سے چھوٹی پائیدار تبدیلی ایک drop-in فائل ہے: Restart=on-failure اور RestartSec=10 جو /etc/systemd/system/[email protected]/restart.conf میں ہیں۔ drop-in صرف اس وقت پڑھی جاتی ہے جب systemd اپنی تعریفیں دوبارہ لوڈ کرتا ہے، اس لیے اس کے بعد systemctl daemon-reload چلائیں۔ قدر پہنچنے کا گمان کرنے کے بجائے systemctl show -p Restart -p ExecMainStatus openvpn-client@office سے تصدیق کریں۔ فائل کے نام میں موجود انسٹانس وہی پروفائل ہونا چاہیے جو یونٹ واقعی لوڈ کرتا ہے، اس لیے office کے لیے لکھی گئی فائل openvpn-client@home کے لیے کچھ نہیں کرتی۔

on-failure ایک صورت نظرانداز کرتا ہے: صفر حیثیت کے ساتھ صاف اخراج۔ کچھ انہدامی راستے اسی طرح ختم ہوتے ہیں، اس لیے مینوئل صفحے کے الفاظ پر بھروسا کرنے کے بجائے درج حیثیت پڑھیں۔ اگر آپ کا کلائنٹ صفر کے ساتھ ہار مان جائے تو آپ کو Restart=always درکار ہے، اور اس کی قیمت یہ ہے کہ واقعی خراب پروفائل بار بار واپس آتا ہے جب تک آغاز کی رفتار کی حد فعال نہ ہو اور جرنل بھر نہ جائے۔

Restart=always جان بوجھ کر روکنے کے بعد بھی کام کرتا ہے۔ دیکھ بھال کے لیے systemctl stop استعمال کریں، اور اگر آپ کے کام کے دوران یونٹ بند رہنا ضروری ہو تو اسے ماسک کریں۔

سرنگ بند ہونے کے دوران رساؤ پکڑیں

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

جب کسی میزبان کو غیر محفوظ پیکٹ بالکل بھیجنے کی اجازت نہ ہو، تو اس کی ضمانت صرف فائر وال ہی دے سکتی ہے۔ ایسا اخراجی قاعدہ جو سرنگ کا انٹرفیس اور VPN سرور کا پتہ اجازت دے اور باقی سب گرا دے، کلائنٹ کی موت کے بعد بھی لاگو رہتا ہے، اور کلائنٹ کی اپنی ترتیب میں کچھ بھی ایسا نہیں جو اس ٹریفک کو فلٹر کر سکے جو کلائنٹ نہیں اٹھا رہا۔

کلائنٹ کو جان بوجھ کر روک کر اسے آزمائیں۔ systemctl stop openvpn-client@office چلائیں، پھر curl -m 5 https://example.com، جو جسمانی لنک پر کامیاب ہونے کے بجائے ناکام ہونا چاہیے۔ کامیابی کا مطلب ہے کہ فائر وال کا قاعدہ غائب ہے یا بہت زیادہ اجازت دینے والا ہے۔

دوبارہ جڑیں، تصدیق کریں کہ سرنگ پھر ٹریفک اٹھا رہی ہے، اور پھر ہی جانچ مانیٹرنگ میں شامل کریں۔ cron سے ip addr کے ذریعے tun آلے کے لیے پوچھنا سب سے زیادہ ناکام ہونے والی نگرانی ہے، کیونکہ persist-tun کے ساتھ آلہ سیشن سے زیادہ زندہ رہتا ہے اور کچھ نہ اٹھنے پر بھی جانچ صحت کی رپورٹ دیتی ہے۔