VPN لاگز کے لیے journalctl: کون سی یونٹ کنکشن کی مالک ہے؟

اُس systemd یونٹ سے شروع کریں جو واقعی VPN کنکشن کی مالک ہے، نہ کہ اُس لاگ کمانڈ سے جو آپ کو یاد ہے۔ براہِ راست OpenVPN سروس، ایک wg-quick یونٹ اور ایک NetworkManager پروفائل اپنے مفید پیغامات مختلف یونٹوں میں رکھتے ہیں، اور غلط یونٹ پر استفسار خالی نتیجہ دیتا ہے جو خاموشی جیسا لگتا ہے۔ تین عام مالکوں کا موازنہ کریں، کھڑکی محدود کریں، پھر مراحل ترتیب سے پڑھیں۔

تین عام مالکوں کا موازنہ کریں

OpenVPN کلائنٹ سروس عام طور پر پروفائل کے نام پر ایک انسٹنس یونٹ ہوتی ہے، مثلاً [email protected]۔ اُس کے پیغامات میں کنفیگریشن کا راستہ، اختیارات کا تجزیہ، TLS مصافحہ اور کلائنٹ کی کی گئی روٹ تنصیب شامل ہیں۔

wg-quick یونٹ بناوٹ ہی سے زیادہ خاموش ہے۔ انٹرفیس کنفیگریشن آغاز پر ہوتی ہے، مصافحہ کرنل سنبھالتا ہے، اور معمول کی کلید تجدید ڈیفالٹ طور پر لاگ نہیں ہوتی، اس لیے wg show اکثر جرنل سے زیادہ معلوماتی ہوتا ہے۔ یہ فرق اُس وقت اہم ہے جب آپ مذاکرات لاگ کرنے والے پروٹوکول کا موازنہ ایسے سے کریں جو ایسا نہیں کرتا۔

NetworkManager اپنے بنائے ہوئے پروفائلز کا مالک ہے، اور بنیادی پلگ اِن VPN معاون ہونے کے باوجود اُس کے پیغامات NetworkManager.service کے تحت رہتے ہیں۔ جب پروفائل اِس طرح منتظم ہو تو مینیجر اور معاون یونٹ دونوں سے پوچھیں۔

استفسار کو ایک یونٹ اور ایک کھڑکی تک محدود کریں

اُس یونٹ سے پوچھیں جس کی آپ نے نشاندہی کی، اور وقت کو اُس کوشش تک محدود رکھیں جس کی آپ تحقیق کر رہے ہیں۔ ایک دن عام طور پر کافی ہوتا ہے، اور جب مشین بار بار دوبارہ جڑتی ہو تو چھوٹی کھڑکی بہتر ہے۔

journalctl -u [email protected] --since today
systemctl list-units --type=service | grep -i vpn
systemctl cat [email protected]

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

پہلا ناکام مرحلہ پڑھیں

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

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

ناکام سروس کو دستی کلائنٹ کے ساتھ نہ ملائیں

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

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

ایکسپورٹ نہیں، اقتباس شیئر کریں

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

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