OpenVPN شروع نہیں ہوتا: کنفیگ نہیں، پہلی سطر پڑھیں

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

وہاں تین صرف پڑھنے والے کمانڈ لے جاتے ہیں: پہلے journalctl -u openvpn@server -b --no-pager، پھر systemctl status openvpn@server، اور UDP سامعین اور اُن کے مالکان کے لیے ss -lunp۔

پہلی سطر شاخ چنتی ہے

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

اُس دوبارہ کوشش کے چکر سے بچیں جو اصل سطر چھپا دیتا ہے۔ دوبارہ آغاز کی پالیسی والا یونٹ پہلی ناکامی کو ایک درجن یکساں سطروں کے نیچے دبا سکتا ہے، اس لیے یونٹ کے حساب سے چھان کر اوپر سے پڑھا جانے والا journalctl -b آخر سے بہتر ہے۔

1194 پورٹ کون اور تھامے ہوئے ہے

قصوروار عموماً دوسرا سرور نہیں ہوتا جسے کسی نے جان بوجھ کر ترتیب دیا ہو۔ کسی اور ٹرمینل میں اب بھی زندہ ہاتھ سے چلایا گیا کلائنٹ، دوسری پروفائل جس نے اتفاقاً وہی پورٹ چن لی، یا کسی وینڈر کا بنڈل جس کا اپنا ٹنل 1194 تھامے ہوتا ہے، متوقع رکھیں۔ ساکٹ کا مالک ss -lunp میں نظر آتا ہے؛ یہ PID systemctl status کو دیں تاکہ معلوم ہو کہ کوئی یونٹ ذمہ دار ہے یا نہیں۔ اُسے سگنل سے نہیں، اپنے کنٹرول راستے سے بند کریں۔

یونٹ کے زیرِ انتظام پروسیس کو دیا گیا سگنل عموماً دوبارہ آغاز کر دیتا ہے، اور وہی ناکامی کچھ لمحوں بعد نئے مسئلے کی طرح لوٹ آتی ہے۔ یونٹ کے لیے systemctl stop استعمال کریں، وینڈر انسٹال کے لیے بنڈل کا اپنا سروس کمانڈ، اور سگنل صرف اُس چیز کے لیے جو آپ نے اُس شیل میں خود ہاتھ سے شروع کی۔

صفائی کے بعد بچے ہوئے یونٹ

صفائی بائنریز کو مٹا دیتی ہے؛ ہاتھ سے لکھی گئی یونٹ فائلیں، عموماً /etc/systemd/system کے نیچے، اُس سے بچ جاتی ہیں۔ پھر Systemd ایسے راستے کی طرف اشارہ کرنے والا یونٹ دوبارہ آزمانے لگتا ہے جو اب موجود نہیں، اور پیغام کل کی ہٹائی کے بجائے اُسی غائب فائل کے بارے میں ہوتا ہے۔ systemctl status یونٹ کا فرگمنٹ راستہ اوپر کے قریب دکھاتا ہے، اس لیے کچھ بھی حذف کرنے سے پہلے dpkg -S سے اُسے جانچیں۔ یتیم ختم ہونے کے بعد systemctl daemon-reload اور systemctl reset-failed حالت صاف کر دیتے ہیں؛ ورنہ ہر بعد کی اسٹیٹس جانچ اُسے ورثے میں لیتی رہے گی۔

جب which openvpn کا جواب /usr/local کے نیچے کچھ ہو، تو زیرِ استعمال بائنری apt سے نہیں بلکہ وینڈر انسٹالر سے آئی ہے۔ ایسا انسٹالر عموماً اپنا سامع، اپنا بوٹ اندراج اور اپنا کنفیگ ڈائریکٹری ساتھ لاتا ہے، اس لیے نظر آنے والا کمانڈ ہٹانے سے ساکٹ مصروف ہی رہتا ہے۔

وینڈر جو دستاویز کرے اُس طریقے سے اُسے اَن انسٹال کریں، ss -lunp سے تصدیق کریں کہ پورٹ خالی ہے، اور ڈسٹری بیوشن کلائنٹ صرف اُس وقت شامل کریں جب آپ کو اُس کی ضرورت ہو۔

دوبارہ کوشش سے پہلے حالت طے کریں

اُس سے نتیجے نکالنے سے پہلے ناکام حالت صاف کریں: systemctl reset-failed کاؤنٹرز ہٹاتا ہے، اور پھر systemctl status یونٹ کی تاریخ کے بجائے اُس کی موجودہ حالت بتاتا ہے۔ اُسے ایک بار شروع کریں اور باکس کی مجموعی حالت کے بجائے اُسی مثال کا اپنا لاگ پڑھیں۔ ایسا یونٹ جو فعال رپورٹ کرے جبکہ ٹنل کچھ بھی نہ ڈھوتا ہو، الگ مسئلہ ہے اور کہیں زیادہ عام۔ بگ رپورٹوں میں دونوں گھل مل جاتے ہیں کیونکہ دونوں کا اختتام صارف کے یہ کہنے پر ہوتا ہے کہ VPN کام نہیں کرتا۔

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