OpenVPN 3 Linux: واپس جانے سے پہلے D-Bus کی خرابی پڑھیں
پانچ سروسز، ایک فرنٹ اینڈ۔ D-Bus کی خرابی کو اُس جزو سے منسوب کریں جس نے انکار کیا، دیکھیں کہ سیشن موجود ہے یا نہیں، پھر اُسی حد پر درستی کریں۔
OpenVPN 3 Linux کی ناکامیاں کسی انجان نام کے ساتھ D-Bus کے طریقے کی خرابی کی صورت میں آتی ہیں، اور لالچ یہ ہوتا ہے کہ پیکج کا ورژن نیچے کیا جائے اور امید رکھی جاے۔ کلائنٹ ایک پروگرام نہیں ہے: کمانڈ لائن کا فرنٹ اینڈ بس کے ذریعے اُن سروسز سے بات کرتا ہے جو پروفائلز، سیشنز، VPN انجن اور مراعات یافتہ نیٹ ورک تبدیلیوں کے مالک ہیں۔ یہ طے کرنا کہ اِن پانچ میں سے کون ناکام کال کا مالک ہے، تشخیص کا سب سے بڑا حصہ ہے اور واپسی کے بجاے ایک کمانڈ کا خرچ ہے۔ آگے وہی فیصلہ ہے، اُسی ترتیب میں جس میں ناکامیاں عام طور پر ظاہر ہوتی ہیں۔
ایک کمانڈ کے پیچھے پانچ مالک
پانچ عمل اہم ہیں، اور ہر ایک کا اپنا بس نام ہے: وہ فرنٹ اینڈ جو آپ کی کمانڈ قبول کرتا ہے، کنفیگریشن مینیجر جو پروفائلز اور اُن کی رسائی کی پالیسی رکھتا ہے، سیشن مینیجر جو سیشن کی عمر کا مالک ہے، بیک اینڈ جو OpenVPN 3 Core Engine کے ذریعے کنکشن چلاتا ہے، اور نیٹ ورک کنفیگریشن سروس جو انٹرفیس، راستے اور DNS کی ترتیبات نصب کرتی ہے۔ اس لیے کنفیگریشن آبجیکٹ کا نام لینے والی خرابی بیک اینڈ کی خرابی نہیں ہے، اور شروع نہ ہونے والا بیک اینڈ تصدیق کی ناکامی نہیں ہے۔ پیغام کو اُن میں سے کسی قطار میں رکھنا کسی بھی تبدیلی سے پہلے ہونا چاہیے، کیونکہ ہر اگلا قدم اِس پر منحصر ہے کہ کون سی قطار سچی ہے۔ قطار کا اندازہ لگانا وہ راستہ ہے جس پر ایک مختصر درستی پیکجوں کے ساتھ دوپہر کا کام بن جاتی ہے۔
کوئی بھی اور چیز پوچھنے سے پہلے سسٹم بس سے پوچھیں کہ کون سی سروسز موجود ہیں، پھر تصدیق کریں کہ نصب شدہ حصے ایک ورژن پر متفق ہیں۔ OpenVPN 3 Linux اِن سروسز کو سسٹم یونٹس کے طور پر رجسٹر کرتا ہے، اس لیے پوچھی جانے والی بس سسٹم بس ہے، ورژن کی استفسار کے لیے انتظامی اختیار درکار ہے، اور --user کے ساتھ بنائی گئی فہرست آپ کے لاگ اِن سیشن کو پڑھتی ہے، جہاں یونٹس کبھی ظاہر نہیں ہوتے۔ سروسز طلب پر فعال ہوتی ہیں اور کچھ بیکار ہونے پر ختم ہو جاتی ہیں، اس لیے آپ کی پہلی درخواست سے پہلے غائب سروس سے محض کسی چیز کے بارے میں ابھی پوچھا ہی نہیں گیا۔ نیچے دی گئی تین کمانڈز VPN سیشن کھولے بغیر موجودگی، ورژن اور یونٹ کی حالت کا جواب دیتی ہیں۔
sudo busctl list | grep -i openvpn
sudo openvpn3-admin version --services
systemctl list-units 'openvpn3*'ہر فہرست درحقیقت کیا ثابت کرتی ہے
خود کلائنٹ کے مناظر دستیاب سب سے سستا ثبوت ہیں، اور اِن میں سے ہر ایک اِس سے کم ثابت کرتا ہے جتنا نظر آتا ہے۔ کنفیگریشن فہرست میں پروفائل یہ دکھاتا ہے کہ پروفائل درآمد ہو چکا ہے اور اِس بارے میں کچھ نہیں کہ کوئی اُس سے منسلک ہو سکتا ہے یا نہیں۔ سیشنز کی فہرست میں سیشن یہ دکھاتا ہے کہ سیشن آبجیکٹ موجود ہے اور اِس بارے میں کچھ نہیں کہ دور کی تصدیق مکمل ہوئی یا نہیں۔
openvpn3 configs-list
openvpn3 sessions-listاِن آؤٹ پٹس میں آبجیکٹ کے راستے بس پر منظم آبجیکٹ کی نشاندہی کرتے ہیں، فائلوں کی نہیں، اس لیے اُنہیں ایڈٹ نہیں کیا جا سکتا، اور پہلے درج کیا گیا راستہ اُس لمحے پرانا ہو جاتا ہے جب وہ سیشن منقطع ہوتا ہے۔ اپنے نوٹس میں سے کسی ایک کو دوبارہ استعمال کرنا "no such object" خرابیاں پیدا کرتا ہے جن کا VPN سے کوئی تعلق نہیں۔ نیچے دیا گیا مرحلوں کا جدول یہ الگ کرتا ہے کہ کنکشن کا ہر قدم کیا قائم کرتا ہے اور کیا کھلا چھوڑ دیتا ہے، اور واپسی کا فیصلہ بالکل اِسی فرق پر ٹکا ہے۔ اپنے ثبوت سے مطابق قطار پڑھیں، پھر خرابی کا متن دوبارہ پڑھیں۔
| Stage | What exists | What proves it | What it does not prove |
|---|---|---|---|
| Profile imported | A configuration object held by the configuration manager | The profile is listed by the client | That the profile owner permits a connection |
| Session requested | A session object held by the session manager | The session appears in the session list | That the remote side accepted the credentials |
| Connect dispatched | An asynchronous attempt on the VPN backend | Status changes arrive for that session | That an interface was configured |
| Tunnel configured | An interface, routes and DNS settings | The network service reports success and routes appear | That traffic reaches the peer |
کنکشن کی کال سرنگ موجود ہونے سے پہلے واپس آ جاتی ہے
کنکشن کی کال آپ کو نگرانی کے لیے سیشن دیتی ہے اور واپس آ جاتی ہے، اِسی لیے بظاہر کامیاب کال کے بعد خاموشی ایک معمولی درمیانی حالت ہے، تضاد نہیں۔ فرنٹ اینڈ کو پھر بھی حالت کی تبدیلیوں کی پیروی کرنی ہے اور تعامل کی ہر درخواست کا جواب دینا ہے۔ ایسا پروفائل جسے سند درکار ہو اور جواب نہ ملے، ایسی حالت میں انتظار کرتا ہے جو بالکل اٹکے ہوئے بیک اینڈ جیسی دکھتی ہے۔ اُس انتظار کی حالت کو پہچانا جانا چاہیے، کیونکہ یہ لوگوں کو غلط جزو کی طرف بھیجتی ہے۔
جب کوئی کوشش جاری ہو، اُس پروفائل کے لیے سیشنز کی فہرست اور فرنٹ اینڈ کے اپنے لاگ پر نظر رکھیں۔ جو سیشن اپنی ابتدائی حالت کبھی نہیں چھوڑتا وہ اُس جزو کا نام لیتا ہے جو رک گیا، اور لاگ عموماً پہلی ہی سطروں میں اُس کا نام لے لیتا ہے۔ پروفائل کا نام قریب رکھیں، کیونکہ لاگ کی کمانڈ سیشن کا راستہ نہیں بلکہ پروفائل لیتی ہے، جو راستہ دوبارہ استعمال کرنے کے بجاے فہرست دوبارہ پڑھنے کی ایک اور وجہ ہے۔
openvpn3 sessions-list
openvpn3 log --config <profile> --level 6سیشن کھولے بغیر ایک جزو کا لاگ پڑھنا
جب فرنٹ اینڈ کوئی کارآمد بات نہ بتائے، تو نئی کنکشن شروع کرنے کے بجاے اُس جزو کی طرف جائیں جس نے خرابی لاگ کی۔ ترتیب شدہ systemd-journald لاگر کے ساتھ، منتظم کا محدود جرنل منظر ایک جزو کے واقعات پڑھتا ہے، بس کی پالیسی کو چھوئے بغیر اور سیشن کھولے بغیر، اور یہ اہم ہے کیونکہ وہ تشخیص جو اُس نظام کو بدل دے جسے وہ ناپ رہی ہے، بہت کم ثابت کرتی ہے۔ یونٹ کے مطابق چھانٹیں، syslog ٹیگ کے مطابق نہیں: الگ الگ سروس یونٹس مشترک شناخت کی ضمانت نہیں دیتے، اس لیے ٹیگ کی استفسار خالی صفحہ واپس کر سکتی ہے جبکہ خود یونٹ نے خرابی درج کی ہو۔
کسی سے مدد مانگنے سے پہلے چار خانے لکھ لیں: خرابی کا پورا نام، متعلقہ سروس اور آبجیکٹ، وقت کی مہر، اور نصب شدہ پیکجوں کے ورژن۔ یہی وہ چیزیں ہیں جو دیکھ بھال کرنے والے کو درکار ہوتی ہیں، اور اِن میں سے کسی کے لیے پروفائل یا سند کو ٹکٹ میں چپکانا ضروری نہیں۔ خرابی کو خاموش کرنے کے لیے بس کی رسائی کی پالیسی کو وسیع کرنا تشخیص نہیں ہے، یہ اُس حد کو مٹا دیتا ہے جو آپ کی جگہ جزو کا نام لے رہی تھی۔ پروفائلز کا نجی مواد مشترکہ رپورٹس سے باہر رہتا ہے، اُسی وجہ سے جس وجہ سے سندیں باہر رہتی ہیں۔
journalctl -u 'openvpn3-service-*' -n 50 --no-pager
openvpn3-admin journal --service <name>اُس حد کی درستی جو انکار کر گئی
نقشے کی ہر قطار کی اپنی درستی ہے، اور قطاریں ایک دوسرے کی جگہ نہیں لیتیں۔ پروفائل پر مسترد شدہ کارروائی پالیسی اور ملکیت کا سوال ہے، جبکہ فعال نہ ہونے والا بیک اینڈ سروسز اور پیکیجنگ کا سوال ہے۔ تصدیق کو مسترد کرنے والا سرور اِن میں سے کوئی نہیں، اس لیے بار بار پاس ورڈ بدلنا مقامی فعال سازی کا مسئلہ درست نہیں کر سکتا۔ غلط درستی چننا وہ راستہ ہے جس پر پالیسی کا مسئلہ دوبارہ تنصیب بن جاتا ہے۔
پیکجوں کی تبدیلی کے بعد کسی پرانی بائنری کو اُس کی جگہ نقل کرنے کے بجاے ایک ہم آہنگ اور معاون تنصیب کی تصدیق کریں۔ کنٹرول شدہ واپسی کسی تصدیق شدہ رجعت کا جائز جواب ہے، بشرطیکہ پیکج مطابقت پذیر رہیں اور معاون دیکھ بھال کی طرف واپسی کا راستہ موجود ہو۔ یہ راستہ سروس کے شروع ہونا بند کرنے سے پہلے قائم کریں، بعد میں نہیں۔
کوئی دوسرا پلیٹ فارم وہی بنیادی VPN لائبریری شیئر کر سکتا ہے بغیر لینکس کی بس سروسز شیئر کیے، اس لیے ونڈوز پر ملتی جلتی ناکامی اِس بارے میں کچھ نہیں کہتی۔ D-Bus کا جائزہ اُن آبجیکٹ راستوں کی دستاویز کرتا ہے جو کنفیگریشنز اور سیشنز کے لیے فراہم کیے جاتے ہیں، اور یہی وہ حصہ ہے جس پر یہ تشخیص کھڑی ہے۔ ایک بار پڑھیں، اور اگلی خرابی ایک ایسے جزو کے ساتھ آئے گی جو پہلے ہی اُس سے جڑا ہوا ہے۔