OpenVPN بغیر کسی غلطی کے شروع نہیں ہوتا؟ journal دیکھیں

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

آؤٹ پٹ کو چار جگہیں جذب کرتی ہیں: unit کا journal، وہ پلگ ان جو کنکشن کا مالک ہے، سرنگ کا دوسرا سرا، اور ایک مختلف بائنری جو آپ کے خیال میں چل رہی ہے۔ ہر ایک کی اپنی جانچ ہے۔

خاموشی کا مطلب ہے کہ آپ درست چینل نہیں دیکھ رہے تھے

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

systemctl status openvpn-client@office
journalctl -u openvpn-client@office -b --no-pager

صاف اخراج کو سگنل سے الگ کرنے کے لیے شامل کریں systemctl show -p Result -p ExecMainStatus openvpn-client@office۔ حالت 1 اور Result=exit-code پروگرام کا فیصلہ ہے؛ Result=signal یا ٹائم آؤٹ اس کے بجائے ماحول کی طرف اشارہ کرتے ہیں، اور پروفائل کی کوئی تدوین اسے نہیں بدلے گی۔ کچھ بھی دوبارہ شروع کرنے سے پہلے دونوں اقدار لکھ لیں، کیونکہ دوبارہ شروع کرنا وہ عارضی حالت مٹا دیتا ہے جس نے انہیں پیدا کیا۔

instance کا نام راستے کا حصہ ہے

پیک شدہ ٹیمپلیٹ unit فائل کا راستہ نہیں لیتا۔ یہ instance کا نام لیتا ہے، اور پروفائل تلاش کرنے کے لیے وہ نام ایک ڈائریکٹری میں شامل کیا جاتا ہے: office Debian اور Ubuntu پیکجنگ میں /etc/openvpn/client/office.conf میں حل ہوتا ہے۔ office-v2.conf نام کی فائل @office کے طور پر شروع کی جائے تو بھی کبھی نہیں پڑھی جاتی، اور unit خاموشی سے باہر نکل جاتا ہے کیونکہ اس کے نقطہ نظر سے کرنے کو کچھ نہیں تھا۔ تلاش کی ڈائریکٹری client اور server موڈ میں مختلف ہے، اس لیے ٹیمپلیٹ بدلنے پر وہی غلطی بالکل کسی اور جگہ اشارہ کرتی ہے۔

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

ls -l /etc/openvpn/client/
systemctl list-units 'openvpn*' --all

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

جب پلگ ان سرنگ کا مالک ہو، ٹرمینل کچھ نہیں دیکھتا

ڈیسک ٹاپ ایپلٹ سے شروع ہونے والا کنکشن NetworkManager کی ملکیت ہے، اور اس کا OpenVPN آؤٹ پٹ آپ کے کھولے ہوئے کسی شیل میں نہیں بلکہ اسی سروس کے journal میں جاتا ہے۔ کلائنٹ کو ہاتھ سے چلانا اور کچھ نہ دیکھنا اس ترتیب میں متوقع ہے، کیونکہ ہاتھ سے چلایا گیا عمل وہ نہیں جو کنکشن اٹھائے۔

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

journalctl -b -u NetworkManager --no-pager | grep -i -A3 openvpn
openvpn --config /etc/openvpn/client/office.conf --verb 4 --log /tmp/ovpn.log

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

دو بائنری، ایک PATH

ہاتھ سے بنایا گیا انسٹال جو /usr/local کے تحت ہے شیل کال میں جیتتا ہے، کیونکہ /usr/local/sbin ڈیفالٹ Ubuntu PATH میں /usr/sbin سے پہلے آتا ہے۔ unit آپ کا PATH استعمال نہیں کرتا؛ یہ ExecStart میں لکھا مطلق راستہ چلاتا ہے۔ اس لیے آپ کے ٹرمینل میں کام کرنے والا ورژن اور سروس کے طور پر ناکام ہونے والا ورژن واقعی مختلف پروگرام ہو سکتے ہیں۔

کچھ بھی دوبارہ بنانے سے پہلے دونوں کا موازنہ کریں۔ تیسرا کمانڈ ہی بحث کا فیصلہ کرتا ہے۔

command -v openvpn
whereis openvpn
systemctl cat openvpn-client@office | grep ExecStart

ایک اور ماحولیاتی فرق اسی جگہ چھپا ہے۔ پیک شدہ unit /run کے تحت systemd کی بنائی ہوئی رن ٹائم ڈائریکٹری پر انحصار کرتا ہے؛ ہاتھ سے لکھا گیا متبادل unit جو وہ ترتیب چھوڑ دے ایک بھی فائل کھولنے سے پہلے ناکام ہو سکتا ہے، اور ناکامی کسی OpenVPN پیغام کے بغیر عام انکار جیسی دکھتی ہے۔

وہ ناکامیاں جن کی کلائنٹ رپورٹ نہیں کر سکتا

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

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

تہوں کو ترتیب سے نمٹائیں: unit موجود ہے اور instance کا نام درست ہے، journal یا --log فائل تک کچھ پہنچا، کون سی بائنری اور پروفائل واقعی چلے، اور ناکامی مقامی ہے یا دور کی۔ ہر جواب ایک تہہ ہٹاتا ہے۔ پروفائل سے شروع کرنا اس فائل کو دوبارہ لکھنا ہے جو شاید کبھی کھولی ہی نہ گئی ہو۔