OpenVPN شروع ہوا مگر کچھ نہیں چھاپا: پہلے log-append دیکھیں

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

خاموشی کی دو بالکل مختلف وضاحتیں ہیں

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

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

ہدایت تلاش کریں، پھر عمل تلاش کریں۔

ps -o pid,args= -C openvpn
grep -nE '^\s*(log|log-append|cd|daemon|verb)\b' /etc/openvpn/server/server.conf

چل رہے عمل کا استعمال کردہ منزل تلاش کریں

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

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

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

log بمقابلہ log-append: ثبوت اور مٹانا

log-append فائل میں پہلے سے موجود چیز میں اضافہ کرتا ہے۔ log فائل کو لکھنے کے لیے کھولتا ہے اور اسے کاٹ دیتا ہے، اس لیے دونوں کے درمیان بدلنا وہ رن مٹا سکتا ہے جو آپ پڑھنے والے تھے۔

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

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

جب سروس ریپر آؤٹ پٹ پکڑتا ہے

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

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

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

تفصیل صرف اس وقت بڑھائیں جب آپ اسے پڑھ سکیں

منزل تلاش کرنے سے پہلے تفصیل بڑھانا صرف اس جگہ زیادہ متن پیدا کرتا ہے جہاں آپ نہیں دیکھ رہے۔

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

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