OpenVPN کہتا ہے active (exited)؟ وہ انسٹنس تلاش کریں جو آپ نے شروع کیا

آپ ٹنل کی جانچ کرتے ہیں، systemctl status openvpn چلاتے ہیں اور Main PID کے بغیر اور خالی پروسیس فہرست کے ساتھ active (exited) پاتے ہیں۔ قدرتی پڑھائی یہ ہے کہ سروس شروع ہو کر مر گئی، اس لیے آپ unit کھولتے ہیں، /bin/true ڈھونڈتے ہیں اور نتیجہ نکالتے ہیں کہ پیکیج ٹوٹا ہوا ہے۔ Debian پیکیجنگ میں وہ حالت ڈیزائن کے مطابق کام کرنے والا wrapper ہے، اور ٹنل اسی کے شروع کردہ instance unit میں سے ایک میں رہتا ہے۔ مجموعی unit کبھی نہیں بتائے گا کہ کس انسٹنس نے اسے بنایا۔

اس unit پر active (exited) کا اصل مطلب کیا ہے

پیکیج شدہ unit ایک بار کا کام ہے: اس کا ExecStart /bin/true ہے، اور مکمل ہوئے unit کے active (exited) کے طور پر رپورٹ رہنے کی وجہ RemainAfterExit=yes ہے۔ وہ ہدایت ہٹا دیں تو وہی کامیاب /bin/true کام inactive (dead) میں ختم ہوتا ہے، جو بالکل وہی حالت ہے جس کی لوگ توقع کرتے ہیں اور الٹی سمت میں غلط پڑھتے ہیں۔ کمانڈ محض جگہ بھرنے والی ہے، اور unit دوسرے unit کے کیے کام کی رپورٹ دیتا ہے۔ اس ترتیب میں کچھ بھی ٹوٹا نہیں، اور /bin/true بدلنا ٹنل نہیں بلکہ پیکیجنگ معاہدہ بدلتا ہے۔

wrapper نمائندگی کرتا ہے۔ یہ وہ instance unit شروع کرتا ہے جو پیکیج کی تشکیل یا اس کا systemd جنریٹر فراہم کرتا ہے، اسی لیے خالی پروسیس فہرست ٹنل کے بارے میں کچھ ثابت نہیں کرتی۔ جب کوئی انسٹنس منتخب نہ ہو تو بھی wrapper کامیاب ہوتا ہے اور کچھ شروع نہیں کرتا۔ حالت بتاتی ہے کہ wrapper چلا یا نہیں، نہ کہ ٹنل موجود ہے یا نہیں۔

قوسین کے لفظ کی بجائے status کی تین سطریں پڑھیں۔ Loaded اس unit فائل کا نام دیتا ہے جو systemd نے پڑھی، Active آخری کامیاب چلنے کا وقت-مہر رکھتا ہے، اور Main PID کا نہ ہونا مکمل ہوئے ایک بار کے کام سے مطابقت رکھتا ہے۔ وہی تین سطریں اس wrapper کو شروع ہونے کے ایک سیکنڈ بعد گرنے والی سروس سے الگ پہچاننے کا طریقہ بھی ہیں۔

status دوبارہ پڑھنے سے پہلے unit کی فہرست بنائیں

کیا چل رہا ہے پوچھنے سے پہلے systemd سے پوچھیں کہ کیا موجود ہے۔ کوئی انسٹنس بنائے بغیر ٹیمپلیٹ نصب ہو سکتا ہے، اور صرف بنا ہوا unit ٹنل رکھتا ہے۔ لوڈ شدہ سیٹ سے شروع کریں:

systemctl list-units 'openvpn*'

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

systemctl list-unit-files 'openvpn*'

دونوں فہرستیں اکٹھی پڑھیں، کیونکہ دوسری میں ٹیمپلیٹ اور پہلی میں انسٹنس دو مختلف جواب ہیں۔ موجود ٹیمپلیٹ اور چلتا انسٹنس ایک ہی حقیقت نہیں، اور صرف دوسرا ٹنل کے معنی میں ہے۔ پیکیج ترتیبیں تقسیموں اور OpenVPN ورژنوں کے درمیان بھی مختلف ہوتی ہیں۔ پرانا openvpn@ ٹیمپلیٹ، الگ client اور server جوڑی، اور تقسیم کا wrapper سب اپنی پیکیجنگ میں جائز ہو سکتے ہیں۔

اپنی مشین کے مطابق ڈھلیں، نہ کہ ملنے والے ٹیوٹوریل کے مطابق۔ کسی اور کے آؤٹ پٹ میں انسٹنس کا نام office ہو سکتا ہے جبکہ آپ کا home یا work ہے۔ جو منتقل ہوتا ہے وہ طریقہ ہے، سٹرنگ نہیں۔

انسٹنس کے نام سے اس فائل تک جائیں جو یہ پڑھتا ہے

upstream client ٹیمپلیٹ میں unit کی ورکنگ ڈائریکٹری /etc/openvpn/client ہے اور اس کی کمانڈ وہاں سے %i.conf لیتی ہے، اس لیے openvpn-client@office /etc/openvpn/client/office.conf پڑھتا ہے۔ مثال پر بھروسہ کرنے کی بجائے نصب شدہ unit پر اس میپنگ کی تصدیق کریں، کیونکہ آپ کا ٹیمپلیٹ پرانا یا تقسیم کا دوبارہ لکھا ہوا ہو سکتا ہے:

systemctl cat [email protected]

اس آؤٹ پٹ کے نیچے دکھنے والے drop-in پڑھیں، کیونکہ .d/ کے نیچے کی فائل ExecStart، ورکنگ ڈائریکٹری یا ترتیب کا راستہ بدل سکتی ہے۔ آپ نے office.ovpn کے نام سے جو پروفائل ڈاؤن لوڈ کی، وہ وہ فائل نہیں جو انسٹنس کھولتا ہے۔ یہی فرق عام طور پر وہ راستہ بتانے کی وجہ ہے جو آپ نے کبھی ترمیم نہیں کیا۔

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

اسے شروع کریں، پھر اسی انسٹنس کا جرنل پڑھیں

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

sudo systemctl start [email protected]
journalctl -u [email protected] -b

شروع کرنا اور فعال کرنا الگ فیصلے ہیں: start unit کو ابھی چلاتا ہے، enable اگلے بوٹ کا انتظام کرتا ہے، اور enable --now دونوں ایک قدم میں کرتا ہے۔ daemon-reload unit تعریفات دوبارہ پڑھتا ہے اور چلتی ہوئی پروسیس دوبارہ شروع نہیں کرتا یا ترمیم شدہ پروفائل لاگو نہیں کرتا۔ پروفائل بدلنے کے بعد انسٹنس دوبارہ شروع کریں، کیونکہ فائل دوبارہ پڑھنے والا وہی ہے۔

اسی ٹنل پر دوسرا مینیجر نہ رکھیں

NetworkManager اور OpenVPN 3 سیشن مینیجرز کی اپنی کنکشن حالت ہوتی ہے، اور ان میں سے کسی کے ساتھ systemd انسٹنس اسی ٹنل پر دو مالک رکھ دیتا ہے۔ علامت یہ ہے کہ ٹنل اوپر آتی ہے اور چند سیکنڈ بعد بدل دی جاتی ہے، یا رکی رہنے سے انکار کرتی ہے۔ وہ مینیجر منتخب کریں جسے آپ کی تقسیم ڈیسک ٹاپ کے لیے دستاویز کرتی ہے، اور سرور پر systemd جان بوجھ کر استعمال کریں۔

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

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