DH فائل یا tls-auth کلید؟ دو OpenVPN فائلوں میں فرق

دو فائلیں، دو ہدایات، اور دونوں کو اسی چیز کے نام سے پکارنے کی عادت جسے وہ ترتیب دیتی ہیں۔ اسی طرح dh.pem tls-auth لائن میں پہنچ جاتی ہے اور کلائنٹ غیر متوقع کلید کی شکل کے بارے میں پیغام کے ساتھ ناکام ہوتا ہے۔ آپ کے سامنے فیصلہ یہ نہیں کہ کون سی فائل زیادہ مضبوط ہے۔ یہ ہے کہ تعیناتی کو واقعی کون سا کردار درکار ہے، اور تین شرطیں اسے طے کرتی ہیں: آپ کا TLS اسٹیک کون سی کلید کی تبدیلی پر بات کرے گا، کیا آپ کو کنٹرول چینل کی تصدیق چاہیے، اور کیا مواد خفیہ رہنا چاہیے۔

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

فائل کے نام سے پہلے لیبل پڑھیں

فائل کی پہلی سطر اس کے نام سے زیادہ معلومات دیتی ہے، کیوں کہ نام انسانی روایت ہے اور لیبل اوزار بناتا ہے۔ Diffie-Hellman پیرامیٹر BEGIN DH PARAMETERS کا PEM لیبل رکھتے ہیں۔ OpenVPN کی مستقل کلید بالکل الگ ساخت ہے، جس کا اپنا سرورق اور ہیکس پے لوڈ ہے۔

نام بدلنے سے کچھ تبدیل نہیں ہوتا۔ ta.key نام کی پیرامیٹر فائل اب بھی پیرامیٹر ہے، اور dh.pem نام کی مستقل کلید اب بھی مستقل کلید ہے؛ تجزیہ کار مواد پڑھتا ہے اور عدم مطابقت مسترد کرتا ہے۔ پروفائل میں ترمیم سے پہلے جانچیں:

head -n 1 dh.pem
head -n 1 ta.key

کون سی فائل درکار ہے، یہ طے کرنے والی تین شرطیں

پہلی شرط تبادلہ ہے۔ محدود میدان کی Diffie-Hellman مصافحہ کو ایک گروپ چاہیے، اور dh ہدایت وہ جگہ ہے جہاں سرور اس کے لیے پیرامیٹر کے نام دیتا ہے۔ بیضوی منحنی مصافحہ کو وہ فائل بالکل درکار نہیں، کیوں کہ منحنی ہی پیرامیٹر کا مجموعہ ہے۔ اگر آپ کا سرور صرف ECDHE سوٹ پر بات کرتا ہے تو DH فائل اضافی طاقت نہیں بلکہ مردہ بوجھ ہے۔

دوسری شرط کنٹرول چینل کی تصدیق ہے، جو اپنے مواد والی الگ خصوصیت ہے۔ tls-auth فائل دونوں فریقوں کے پاس موجود مشترکہ مستقل کلید ہے، جو کنٹرول چینل کے پیکٹوں پر دستخط کے لیے استعمال ہوتی ہے تاکہ غیر تصدیق شدہ فریق مصافحہ بھی مکمل نہ کر سکے۔ یہ محدود میدان کا DH استعمال کریں یا نہ کریں، موجود رہتی ہے، اور گروپ پیرامیٹر سے اس کا کوئی تعلق نہیں۔

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

ہر کردار کے لیے درست مواد بنائیں

وہ اوزار استعمال کریں جو ہدایت کے متوقع فارمیٹ کو بناتا ہے، ان کے درمیان تبدیلی کی بجائے۔ OpenVPN 2.6 کی مشترکہ کلید کے لیے جنریٹر کی ٹائپ شدہ شکل مقصد واضح طور پر بیان کرتی ہے۔

openvpn --genkey tls-auth ta.key

وہ کمانڈ نیا خفیہ مواد بناتی ہے؛ یہ موجودہ کلید کی مرمت یا معائنہ نہیں کرتی، اور دوبارہ چلانے سے آپ کو مختلف کلید ملتی ہے جو دیگر فریقوں کے پاس نہیں۔ بننے والی فائل کو ضرورت مند فریقوں تک کسی بھی مشترکہ راز کے لیے استعمال ہونے والے چینل سے نقل کریں، اور سمت کی روایت یکساں رکھیں: tls-auth کے ساتھ ایک فریق key-direction 0 اور دوسرا key-direction 1 استعمال کرتا ہے۔

DH پیرامیٹر جب درکار ہوں پیرامیٹر بنانے سے آتے ہیں، کلید جنریٹر سے نہیں، اور نتیجہ عوامی ہونے پر بھی ان کا ماخذ اہم ہے۔ نامعلوم ماخذ سے لیا گیا گروپ عوامی ہونے کی وجہ سے قابل اعتماد نہیں ہوتا؛ اسے اب بھی ایسا گروپ ہونا چاہیے جس پر آپ کے فریق متفق ہوں اور جسے اس کے حجم یا بناوٹ نے کمزور نہ کیا ہو۔

dh none کا مطلب کیا ہے اور کیا نہیں

dh none محدود معنی والی حقیقی ہدایت ہے: کوئی محدود میدان پیرامیٹر فائل لوڈ نہیں ہوگی، کیوں کہ مصافحہ بیضوی منحنی Diffie-Hellman استعمال کرتا ہے۔ یہ کسی چیز کو کمزور کرنے کے معنی میں ”DH مرحلہ چھوڑ دو“ کا مخفف نہیں، اور یقیناً OpenVPN کو یہ نہیں کہتی کہ کسی اور فائل کو متبادل کے طور پر قبول کرے۔

غلط پڑھنے سے دو غلطیاں نکلتی ہیں۔ پہلی یہ سمجھنا کہ dh none tls-auth کی ضرورت ختم کر دیتی ہے، حالاں کہ دونوں الگ الگ چیزیں کنٹرول کرتی ہیں۔ دوسری یہ کہ صرف منحنی ترتیب کے ساتھ پرانی dh لائن رکھی جائے اور پھر سوچا جائے کہ سرور واقعی کون سی فائل استعمال کر رہا ہے؛ اگر ہدایت موجود ہو تو فائل پڑھی جاتی ہے، اور وہاں کا ٹوٹا راستہ اس وجہ سے آغاز ناکام کرتا ہے جس کا بات چیت ہونے والے تبادلے سے کوئی تعلق نہیں۔

اگر غلط فائل پہلے ہی تعینات ہو چکی ہے

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

پھر ان دو واقعات کو الگ کریں جنہیں لوگ ملانے کی طرف مائل ہوتے ہیں۔ DH پیرامیٹر فائل شائع کرنا تقریباً بے ضرر ہے، کیوں کہ پیرامیٹر ڈیزائن ہی سے عوامی تھے۔ tls-auth کلید کو بے نقاب کرنا دوسرا واقعہ ہے: کلید اس کے پاس رکھنے والے ہر فریق کے لیے کنٹرول چینل پیکٹ تصدیق کرتی ہے، اس لیے تبدیلی ایک ہوسٹ پر نہیں بلکہ پوری تعیناتی میں مربوط ہونی چاہیے۔

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