GUI جو پروفائل کھولتا ہے اس پر OpenVPN سروس ناکام ہوتی ہے: پانچ جانچیں

ایک ہی مشین پر دو لانچر ایک ہی پروفائل کھولتے ہیں، اور صرف GUI جڑتا ہے۔ فائل درست ہے اور انسٹالر غالباً ٹھیک ہے؛ فرق وہ سیاق ہے جو ہر لانچر openvpn.exe کو دیتا ہے۔ ورکنگ ڈائریکٹری، اکاؤنٹ کی شناخت اور فائل کی خصوصیات سب اسی سیاق کے ساتھ چلتی ہیں۔ انہیں اسی ترتیب سے جانچیں اور پہلی ایسی چیز پر رک جائیں جو خرابی کی وضاحت کرے۔

تصدیق کریں کہ کون سا لانچر ناکام ہوتا ہے

تقسیم ثابت کرنے سے شروع کریں۔ اگر اسی پروفائل راستے کے ساتھ GUI جڑتا ہے اور سروس نہیں، تو فائل کوئی پڑھ سکتا ہے اور سوال یہ بن جاتا ہے کہ کون اور کہاں سے پڑھتا ہے۔ اگر دونوں ناکام ہوں تو پروفائل خراب ہے اور اس میں سے کچھ لاگو نہیں ہوتا۔ سروس کا نام اور وہ عین پروفائل لکھ لیں جو اسے لوڈ کرنے کو کہا گیا تھا۔

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

متعلقہ راستے کہاں حل ہوتے ہیں

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

ریپر کو شروع ہونے کے لیے کوئی ڈائریکٹری دیں، یا ہر حوالے کو مطلق بنائیں۔ کمانڈ لائن پر GUI کا سیاق دوبارہ بنانا ایسا دکھتا ہے:

openvpn --cd "C:\VPN\profiles\office" --config "C:\VPN\profiles\office\office.ovpn"

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

جب سروس کی شناخت نہ پڑھ سکے

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

جانچ مؤثر اجازتوں کی پڑھائی کے علاوہ سروس کی شناخت کے طور پر کی گئی پڑھائی ہے۔ پہلا حصہ ایلیویٹڈ پرامپٹ سے چلائیں:

icacls "C:\VPN\profiles\office\office.ovpn"

پھر وہی پڑھائی سروس کی شناخت کے طور پر آزمائیں، مثلاً Sysinternals سے psexec -s -i کے ساتھ، اور دیکھیں کہ فائل کھلتی ہے یا نہیں۔ اگر نہ کھلے تو راستے کی کوئی اصلاح مدد نہیں کرے گی۔ ACL ٹھیک کریں یا پروفائل کو ایسی جگہ منتقل کریں جہاں سروس کی شناخت پڑھ سکے۔

فائل کی سطح کی خفیہ کاری دوسرا، کم عام معاملہ ہے۔ Encrypting File System خصوصیت سے نشان زد پروفائل اس صارف کے لیے شفاف طور پر ڈکرپٹ ہوتا ہے جس نے اسے خفیہ کیا، اور سروس اکاؤنٹ کے لیے ناقابلِ قرأت رہتا ہے۔ اسی لیے وہی فائل آپ کے ایڈیٹر میں کھلتی ہے اور سروس کے تحت نہیں۔

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

cipher /s:"C:\VPN\profiles\office"
attrib "C:\VPN\profiles\office\office.ovpn"

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

یہ فیصلہ کرنا کہ سرنگ کا مالک کون ہے

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

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

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

سروس ریپر اصل میں کیا شروع کرتا ہے

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

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

ریپر کو اپنے کنٹرول والی اسکرپٹ سے بدلنا زیادہ دخل انداز ہے، مگر یہ مؤثر کمانڈ لائن کو ایک قابلِ قرأت فائل میں سمیٹ دیتا ہے۔ دوبارہ آغاز کے ساتھ ختم کریں، پھر فی پروفائل لاگ پڑھیں تاکہ پہلی کامیاب اسٹارٹ لائن نظر آئے۔ سروس کی حالت ”چل رہی ہے“ صرف یہ بتاتی ہے کہ ریپر باہر نہیں نکلا، جو اس وقت بھی درست ہے جب اس کی ذیلی عمل فوراً مر گئی ہو۔