L2TP ڈیبگ لاگ خالی ہے؟ غلطی غالباً journal میں ہے

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

چار عمل، لاگ کے دو ٹھکانے

کنکشن IPsec سے شروع ہوتا ہے، جو انسٹالیشن کے مطابق libreswan یا strongSwan ہوتا ہے۔ پھر L2TP ڈیمن، روایتی طور پر xl2tpd اور کچھ بلڈز میں kl2tpd، ٹنل چلاتا ہے۔ آخر میں pppd اس کے اندر توثیق اور پتہ کاری سنبھالتا ہے۔

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

یہ تقسیم یہ بھی بتاتی ہے کہ PSK کی غلطی اور پاس ورڈ کی غلطی ڈیسک ٹاپ سے ایک جیسی کیوں دکھتی ہیں: دونوں ایک عام منقطع پیدا کرتی ہیں، اور ناکام مرحلہ صرف ہر عمل کے آؤٹ پٹ میں نظر آتا ہے۔ یہاں journal کی اہمیت کی پوری وجہ یہی ہے۔ ڈیسک ٹاپ پر ایک عام پیغام، اس کے پیچھے چار ممکنہ مصنفین۔

ایک کوشش جمع کریں، پھر ترتیب پڑھیں

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

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

journalctl -b --no-hostname _COMM=nm-l2tp-service _COMM=pluto _COMM=charon _COMM=xl2tpd _COMM=pppd
rpm -ql NetworkManager-l2tp 2>/dev/null | grep nm-l2tp-service

ایک کال میں دہرائے گئے فیلڈ ان عملوں کا اتحاد منتخب کرتے ہیں، جو ترتیب کو وقت کی ترتیب میں رکھتا ہے۔ Debian پر مبنی نظام میں مساوی استفسار dpkg -L ہے؛ بات یہ ہے کہ ہاتھ سے چلانے سے پہلے یہ معلوم کریں کہ مددگار حقیقت میں کہاں رہتا ہے۔

اگلا قدم تین شرطیں طے کرتی ہیں

پہلا ناکام مرحلہ پڑھیں، پھر اسی کے مطابق انتخاب کریں۔ اگر IPsec تجویز یا ساتھی کی توثیق کی ناکامی کی اطلاع دے، تو ٹنل کبھی بنا ہی نہیں، اور PPP پاس ورڈ بدلنے سے مدد نہیں مل سکتی۔

اگر ٹنل بنا اور pppd نے لاگ ان مسترد کیا، تو مشترکہ راز پہلے ہی درست تھا اور اسناد کا مسئلہ ایک پرت اوپر ہے۔ اگر pppd نے پتے پر بات چیت کی اور ناکامی بعد میں ظاہر ہو، تو دونوں کام کر رہے ہیں اور باقی مسئلہ روٹنگ، DNS یا سرور کی اپنی پالیسی ہے۔

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

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

ڈیبگ موڈ فائلیں پیچھے چھوڑ دیتا ہے

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

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

دستی مثال کو عام مثال کے ساتھ بھی ہم آہنگ کرنا ہوگا۔ جب سروس پہلے ہی پلگ ان کی مالک ہو تو ڈیبگ کاپی شروع کرنا دو مالک اور دونوں کو ملانے والا لاگ بناتا ہے، جو کسی بھی ڈیبگ آؤٹ پٹ نہ ہونے سے بدتر ہے۔

پھر عام مددگار بحال کریں

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

پھر نتیجہ اسی پرت میں تصدیق کریں جو ناکام ہوئی، ڈیسک ٹاپ آئیکن پر نہیں:

journalctl -b -u NetworkManager --since -10min | tail -30
ip -4 addr show ppp0
ip -4 route get 10.20.4.10

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