آپ کا PiVPN پروفائل دراصل کون سا OpenVPN انسٹنس استعمال کر رہا ہے؟

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

مددگار اور ڈیمن الگ الگ چیزیں ہیں

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

systemd میزبان پر ڈائریکٹری کی فہرست کے بجائے فعال یونٹ سے شروع کریں۔ نام پیکیجنگ پر منحصر ہے: Debian اور Raspberry Pi OS کی امیجز عام طور پر ٹیمپلیٹ انسٹنس دیتی ہیں، مثلاً openvpn-server@server, جبکہ پرانی تنصیبات openvpn@server استعمال کرتی ہیں۔ فائل کے نام سے اندازہ لگانے کے بجائے مینیجر سے پوچھیں کہ کون سا چل رہا ہے۔

systemctl list-units --type=service --all | grep -i openvpn
systemctl cat openvpn-server@server

پڑھیں ExecStart= اس آؤٹ پٹ میں۔ یہ قابلِ عمل فائل اور وہ اختیارات بتاتا ہے جو مینیجر واقعی شروع کرتا ہے، بشمول کوئی بھی --config راستہ؛ قریب پڑی اور کسی حکم سے حوالہ نہ دی گئی کنفیگریشن فائل چلتی سرنگ کا حصہ نہیں ہے۔

ڈیمن کی حل کردہ کنفیگ زنجیر کی پیروی کریں

OpenVPN ترتیبات کے لیے ڈائریکٹری اسکین نہیں کرتا۔ یہ --config کے ساتھ دی گئی فائل پڑھتا ہے، اندر کی کسی بھی config ہدایت کی پیروی کرتا ہے، اور پھر کمانڈ لائن اختیارات لاگو کرتا ہے۔ 2.6 کی دستی اس ترتیب کو بیان کرتی ہے، اور یہ اہم ہے جب دو فائلیں پورٹ، ڈیوائس یا سائفر پر متفق نہ ہوں۔

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

systemctl show -p ExecStart --value openvpn-server@server
grep -E '^(config|dev|proto|port|local|log|log-append|status|ca|cert|key|tls-auth|tls-crypt)' /etc/openvpn/server/server.conf

ہوم ڈائریکٹری کی .ovpn فائل کلائنٹ کا نمونہ ہے۔ سرور ڈیمن اسے کبھی نہیں پڑھتا، اس لیے سرور کی طرف کی ہینڈ شیک ناکامی درست کرنے کے لیے وہ فائل ترمیم کرنا کچھ حاصل نہیں کرتا۔

شامل کرنا دوسرا جال ہے۔ ایک config سطر دوسری فائل کھینچ لاتی ہے جس کے اختیارات وہیں پر کارروائی ہوتے ہیں، اس لیے بعد کی ایک قدر والی ہدایت اس بات پر غالب آ سکتی ہے جو مرکزی فائل کہتی دکھائی دیتی ہے۔ اگر نظر آنے والی فائل درست لگے اور ڈیمن پھر بھی مختلف برتاؤ کرے تو کچھ بدلنے سے پہلے شامل فائل پڑھیں۔

لاگ کو عمل سے میچ کریں، اس غلطی سے نہیں جو آپ کو یاد ہے

دو لاگ منزلیں عام ہیں، اور ان میں سے صرف ایک journal ہے۔ log-append مقرر ہونے پر ڈیمن اس فائل میں لکھتا ہے اور journal آغاز کی سطروں کے علاوہ تھوڑا ہی رکھتا ہے۔ اس کے بغیر journalctl واقعات کا ماخذ ہے۔

journalctl -u openvpn-server@server -n 80 --no-pager

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

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

آخری عمومی ناکامی کے بجائے پہلی مخصوص ناکامی درج کریں۔ bind کی غلطی، جواب کے بغیر بیرونی تبادلہ، سرٹیفکیٹ کی نامنظوری اور اکاؤنٹ کی نامنظوری ہر ایک آپ کو الگ تہہ پر بھیجتی ہے، اور آخر میں ٹائم آؤٹ اکثر اوپر کا مفید واقعہ چھپا دیتا ہے۔

سرنگ دوبارہ بنانا تشخیصی مرحلہ نہیں ہے

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

یہی بات tls-auth یا tls-crypt بند کرنے، verify-x509-name ڈھیلا کرنے، یا سبز حیثیت کے لیے دوسرا عنصر چھوڑنے پر بھی لاگو ہوتی ہے۔ جو سرنگ تصدیق ہٹائے جانے کی وجہ سے جڑتی ہے وہ الگ نظام ہے، مرمت شدہ نہیں۔

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

اگلے شخص کو کیا سونپنا ہے

چار حقائق اس وقت تک لکھیں جب تک وہ آپ کے پاس ہیں: OpenVPN کا ورژن openvpn --version سے، فعال یونٹ، شامل کرنے سمیت کنفیگ زنجیر، اور ایک کوشش کا احاطہ کرنے والی لاگ ونڈو۔ وہ چار مبہم شکایت کو دوبارہ پیدا ہونے والے کیس میں بدل دیتے ہیں۔

شیئر کرنے سے پہلے حساس معلومات مٹائیں۔ نجی چابیاں، auth-user-pass فائلیں، جامد چابی کا مواد اور مکمل کلائنٹ بنڈل ٹکٹ میں نہیں ہونے چاہئیں؛ اختیارات کے نام اور زنجیر کی شکل عام طور پر دوسری جوڑی آنکھوں کے لیے کافی ہیں۔

اگر زنجیر غیر محفوظ نہ ہو اور لاگ اب بھی نیٹ ورک کی طرف اشارہ کرے، اگلا قدم کلائنٹ اور سرور کے درمیان راستہ ہے, کوئی اور تنصیب نہیں۔ یہی کہانی کا وہ حصہ ہے جو مددگار کے پاس کبھی نہیں تھا۔