لیپ ٹاپ کے جاگنے کے بعد OpenVPN کیوں مر جاتا ہے؟

نیند OpenVPN سیشن کو مار سکتی ہے اور tun0 پیچھے چھوڑ سکتی ہے۔ ٹنل جانچیں، پھر ڈیوائس نہیں، systemd نیند ہک سے یونٹ دوبارہ شروع کریں۔

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

ip -br address show tun0
ip route get 10.20.0.10
journalctl -u openvpn-client@office -b --no-pager | tail -30

خودکار بنانے سے پہلے جاگنے کی کیفیت دوبارہ پیدا کریں

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

اگر کلائنٹ خود ہی واپس آ جائے، تو ہک بھروسے کی بجائے اضافی الجھن ڈالتا ہے۔ اگر یہ کبھی بحال نہ ہو، تو خودکاری ہی دیانت دار حل ہے۔

systemd نیند ہک اصل میں کہاں رہتا ہے

بہت سے پرانے رہنما /etc/pm/sleep.d کی طرف اشارہ کرتے ہیں، یہ pm-utils کی ملکیت والی ڈائریکٹری ہے اور systemd پر مبنی نیند کبھی اس سے مشورہ نہیں لیتی۔ systemd ہک /usr/lib/systemd/system-sleep/ اور /etc/systemd/system-sleep/ سے پڑھتا ہے، پہلے مرحلہ اور پھر عمل منتقل کرتا ہے، اس لیے pre اور post ہی وہ اقدار ہیں جن پر ہک شاخیں بناتا ہے۔ مقامی نقل کو /etc کے تحت رکھیں، پیکج شدہ فائل میں ترمیم کرنے کے بجائے، اور یاد رکھیں کہ اسکرپٹ منتقلی کے وسط میں root کے طور پر چلتی ہے، اس لیے اسے جلدی واپس آنا چاہیے۔

#!/bin/sh
case "$1" in
  post)
    systemctl --no-block try-restart [email protected]
    ;;
esac
exit 0

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

سروس بحال کریں، tun0 کو اکیلا چھوڑ دیں

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

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

جس وقت کو آپ کنٹرول نہیں کر سکتے اس سے نمٹیں

وائرلیس ایسوسی ایشن اور DHCP اکثر ہک چلنے کے بعد مکمل ہوتے ہیں، اس لیے سرور تک راستہ نہ ہونے کے دوران دوبارہ شروع کرنا ناکام ہو سکتا ہے۔ اس پتے کا تھوڑا انتظار کریں، ایک بار پھر کوشش کریں اور نتیجہ لاگ کریں۔

ناموں کا حل ایک الگ دوڑ ہے، کیونکہ ڈیسک ٹاپ کا نیٹ ورک اسٹیک ٹنل کے اوپر آنے کے بعد بھی DNS بحال کر سکتا ہے۔ کام کرنے والے راستے سے اندازہ لگانے کے بجائے resolvectl query internal.example کے ساتھ تلاشیں الگ جانچیں۔ جو ٹنل درست راستہ دیتی ہے اور کچھ حل نہیں کرتی، وہ DNS مسئلہ ہے، ہک کا مسئلہ نہیں۔

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

متعلقہ مضامین