OpenVPN سرٹیفکیٹ اور کلید کو کیسے حل کرتا ہے: اندرونی PEM یا فائل پاتھ

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

دو ذخیرہ شکلیں، ایک ہدایت

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

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

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

اندرونی بلاک شے کیسے بنتا ہے

اندرونی مواد کنفیگریشن سے نکالا جاتا ہے اور متن کے طور پر PEM پارسر کو دیا جاتا ہے۔ وہ پارسر معمول کی حدوں کی توقع کرتا ہے: BEGIN سطر، base64 پے لوڈ اور ملتی ہوئی END سطر۔ اگر بلاک ناکام کاپی سے کٹ گیا، ڈاؤن لوڈ صفحے نے اسے HTML میں لپیٹ دیا، یا ایسے ایڈیٹر میں کھلا جس نے ڈیش معمول کے بنا دیے، تو پارسر موجود دکھائی دینے والے مواد پر ناکام ہو جاتا ہے۔

<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>

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

جانچیں کہ لوڈ شدہ پروفائل واقعی کون سی شکل استعمال کرتا ہے، یہ نہیں کہ آپ کے ایڈیٹر نے اتفاق سے کون سی فائل کھولی:

grep -nE '^(ca|cert|key) |^<(ca|cert|key)>' client.ovpn

پاتھ کا حوالہ کیسے حل ہوتا ہے

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

نسبتی پاتھ وہی ابہام ورثے میں لیتے ہیں۔ جب آپ ننگا فائل نام دیکھیں، تو یہ فرض کرنے کے بجائے کہ یہ آپ کے ٹرمینل سے ملتا ہے، پوچھیں کہ پیداوار میں عمل کی موجودہ ڈائریکٹری کیا ہے۔

الگ محفوظ سرٹیفکیٹ کے لیے، اس پر کچھ بھی ڈیبگ کرنے سے پہلے آف لائن پارس شے کی تصدیق کرتا ہے:

openssl x509 -in client.crt -noout -subject -issuer -dates
openssl pkey -in client.key -noout -check

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

پارسر کی غلطی کیا بتا سکتی ہے اور کیا نہیں

پارس کی ناکامی مسئلے کو ایک ان پٹ اور ایک مرحلے تک محدود کرتی ہے۔ یہ نہیں بتاتی کہ کلائنٹ نے دو ذخیرہ شکلوں میں سے کون سی استعمال کی، اور یہ بھی نہیں بتاتی کہ شے قبول ہوتی۔ یہ الگ ثبوتوں والے الگ سوالات ہیں۔

پارس کامیاب ہونے کے بعد، اگلی ناکامی کسی بعد کے مرحلے کی ہوتی ہے۔ بھروسے کا انکار، مقصد کی عدم مطابقت یا کلید کی عدم مطابقت لوڈر نہیں، ہم منصب یا TLS تہہ بتاتی ہے۔ اسی فائل کو بار بار بدلنے سے وہ غلطی نہیں ہٹے گی۔

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