tls-auth key-direction: 0 اور 1 مختلف ہونے چاہئیں، ایک جیسے نہیں
tls-auth کے ساتھ دونوں سروں کو مخالف سمتوں کی ضرورت ہے، 0 اور 1، یا دونوں کو یہ ترتیب چھوڑنی ہوگی۔ وہی عدد ناکام ہوتا ہے، اور tls-crypt اسے کبھی استعمال نہیں کرتا۔
سرنگ کا ایک سرا کنٹرول چینل پر ایسی کلید سلاٹ سے دستخط کرتا ہے جسے دوسرا سرا کبھی نہیں جانچتا، اور ایک بھی سند کا تبادلہ ہونے سے پہلے کنکشن تصدیق کی خرابی سے مر جاتا ہے۔ tls-auth کی سمت کی عدم مطابقت ایسی ہی دکھائی دیتی ہے، اور یہ قطعی ہے: وہی دو فائلیں ہر کوشش میں، ہر نیٹ ورک سے ناکام ہوتی ہیں۔ لاگ میں اُس اختیار کا نام نہیں جو آپ ڈھونڈ رہے ہیں، اسی لیے لوگ کبھی نہ ٹوٹی کلیدیں دوبارہ بناتے ہیں اور اسناد دوبارہ جاری کرتے ہیں۔ حل یہ ہے کہ دونوں سروں کو تکمیلی بنایا جائے، یا دونوں کو دو سمتہ رہنے دیا جائے، تصدیق کو کمزور کرنا نہیں۔
ناکامی اسناد سے پہلے آتی ہے
tls-auth کے ساتھ دونوں ساتھی وہی مشترکہ کلید رکھتے ہیں اور ہر ایک اُس سے بنائے گئے دو سلاٹوں میں سے ایک استعمال کرتا ہے: ایک سلاٹ باہر جانے والے کنٹرول پیکٹوں پر دستخط کرتا ہے، دوسرا اندر آنے والوں کی تصدیق کرتا ہے۔ سمت 0 اور سمت 1 یہ کردار اُلٹی ترتیب میں تفویض کرتی ہیں، اس لیے HMAC جانچ کے مطابق ہونے کے لیے جوڑی تکمیلی ہونی چاہیے۔ جب ایک طرف تفویض اُلٹ جائے تو وصول کنندہ غلط سلاٹ میں دستخط ڈھونڈتا ہے اور پیکٹ رد کر دیتا ہے۔ سیشن وہیں ختم ہو جاتا ہے، اسی لیے خرابی پیکٹ کی تصدیق سے متعلق ہے، اسناد کے ذخیرے کے پیدا کردہ کسی چیز سے نہیں۔
قطعیت تشخیص کے لیے اہم ہے، کیونکہ وقت یا راستے کا مسئلہ مختلف نشان چھوڑتا ہے: وقفے وقفے سے ٹوٹنا، ایک سمت کا ناکام ہونا، یا صرف مخصوص نیٹ ورک پر مرنے والا سیشن۔ سمت کی عدم مطابقت ہر بار پہلے مصافحے میں ناکام ہوتی ہے، اور اُنہی دو فائلوں والی دوسری مشین پر بھی ویسے ہی ناکام ہوتی ہے۔ --verb 4 پر لاگ پڑھیں اور آخری سطر کی بجائے پہلا مسترد شدہ پیکٹ ڈھونڈیں۔ اگر وہ رد کسی بھی سند کے تبادلے سے پہلے ہو، تو مشترکہ کلید اور اُس کی سمت جانچنے کے لائق دو چیزیں ہیں۔
| What you see | What it rules out | Next check |
|---|---|---|
| Authentication error before any certificate is sent | The data channel is irrelevant; the control channel never authenticated | Compare tls-auth and its direction on both ends |
| Certificate or handshake failure after the control channel authenticates | The shared key and its direction already agree | Check the CA, the certificate dates and the hostname |
| Session completes but throughput or cipher warnings appear | Direction was never the problem | Compare the data-channel cipher settings |
| Startup stops on an options error | The number itself is not the issue | Re-read the inline versus external directive syntax |
عدد کہاں رہتا ہے
OpenVPN 2.6 کا دستورالعمل سمت کے لیے دو جگہیں درج کرتا ہے: tls-auth کی دوسری دلیل جب کلید الگ فائل میں ہو، اور الگ key-direction سطر جب کلید پروفائل میں شامل ہو۔ دونوں ایک ہی قدر مقرر کرتے ہیں، اس لیے پروفائل کو ایک شکل یا دوسری استعمال کرنی چاہیے، کبھی دونوں نہیں۔ چھوڑ دینا بھی ایک انتخاب ہے، اور یہ دونوں ساتھیوں کو دو سمتہ ترتیب میں رکھتا ہے جو اُس وقت کام کرتی ہے جب کوئی فریق سمت نہ بتائے۔ ایک ہی عدد والے دو ساتھی اُس ترتیب میں نہیں ہیں: ہر ایک ایک سلاٹ میں دستخط اور دوسرے میں تصدیق کی توقع کرتا ہے، اور دونوں یہ ایک ہی طرح کرتے ہیں۔
# server.conf, external key tls-auth ta.key 0 # client.ovpn, external key tls-auth ta.key 1 # client.ovpn, inline key key-direction 1
شامل شکل اپنی سطر پر ایک ہدایت ہے، کلید بلاک کے کھلنے والے ٹیگ پر خصوصیت نہیں، اور اُس ٹیگ میں دلیل شامل کرنا خرابی ہے، سمت کی تبدیلی نہیں۔ جگہ بھی اہم ہے: ہدایت اُس بلاک سے باہر ہے جس کی وہ ہے، اس لیے بلاک کے اندر لکھی قدر کلید کے مواد کے طور پر پڑھی جاتی ہے۔ پروفائل کے تقسیم کنندہ کی مطلوبہ ترتیب نقل کریں، جوڑی ایجاد کرنے کی بجائے، کیونکہ ایک سرور کے خلاف کام کرنے والا پروفائل شاید دوسری طرف پہلے ہی منعکس ہو چکا ہو۔
اختیار کیا نہیں چھوتا
یہ ایپلیکیشن ٹریفک کو خفیہ نہیں کرتا۔ tls-auth کنٹرول چینل کے پیکٹوں کے گرد HMAC رکھتا ہے، جبکہ ڈیٹا چینل مصافحے کے دوران طے شدہ سیشن کلیدوں سے محفوظ رہتا ہے، اس لیے تھروپٹ یا سائفر کا سوال سمت کے عدد سے کوئی تعلق نہیں رکھتا۔ ترتیب دوسری خفیہ کاری کی تہہ بھی شامل نہیں کرتی، اور یہی مفروضہ لوگوں کو لمبی کلید ڈھونڈنے بھیجتا ہے۔
یہ tls-crypt پر لاگو نہیں ہوتا، کنٹرول چینل کا ایک اور طریقہ کار جس کے اپنے اختیارات اور کلید کی دیکھ بھال ہے، اور یہ کسی بھی ساتھی کی سند کی شناخت کے بارے میں کچھ نہیں کہتا۔ اس لیے کام کرنے والی سمت کی مطابقت صرف یہ ثابت کرتی ہے کہ دونوں سرے کنٹرول چینل کی تصدیق کے طریقے پر متفق ہیں، یہ نہیں کہ اعتماد کا سلسلہ تصدیق شدہ ہے۔
جوڑی ہم آہنگ کریں، پھر دوبارہ جڑیں
کسی ایک کو بدلنے سے پہلے دونوں ترتیبات کا موازنہ کریں، کیونکہ پہلے سے درست طرف میں ترمیم کام کو دگنا کر دیتی ہے۔ نیچے کا grep دکھاتا ہے کہ ہر فائل کون سا طریقہ کار چنتی ہے؛ تفصیلی چلانا دکھاتا ہے کہ کنٹرول چینل کی تصدیق ہوئی یا نہیں۔ دونوں آؤٹ پٹ رکھیں، تاکہ اگلی تبدیلی معلوم حالت سے موازنہ کی جا سکے۔
grep -n -E 'tls-auth|tls-crypt|key-direction' server.conf client.ovpn openvpn --config client.ovpn --verb 4 2>&1 | grep -i -E 'hmac|tls error|control channel'
کسی بھی تبدیلی کے بعد دونوں ساتھیوں کو دوبارہ شروع کریں، کیونکہ یہ اختیارات آغاز میں ایک بار پڑھے جاتے ہیں اور ایک طرف کو دوبارہ لوڈ کرنا جوڑی کو پرانے سیشن کی پوری زندگی کے دوران متضاد چھوڑ دیتا ہے۔ اگر تعیناتی ابھی سمت مقرر کیے بغیر کام کر رہی ہے، تو ایک ساتھی پر ترتیب شامل کرنا وہی ناکامی دوبارہ پیدا کرتا ہے جس سے آپ نے آغاز کیا؛ یا دونوں کو رہنے دیں یا دونوں کو ترتیب دیں۔ ایک وقت میں ایک سرا بدلیں اور پچھلی فائل رکھیں، تاکہ رجعت دوبارہ تعمیر نہیں، دو منٹ کی واپسی ہو۔
ہر سرے کے لیے طریقہ کار، کلید فائل اور سمت تعیناتی نوٹس میں درج کریں، ورنہ اگلا شخص دو ملتی جلتی فائلیں پڑھے گا اور سمجھے گا کہ اعداد کو ایک دوسرے سے مطابقت رکھنی چاہیے۔ سمت ہم آہنگی کی تفصیل ہے، سیکیورٹی کی بہتری نہیں: یہ کنٹرول چینل کی دو سمتوں کو الگ کرتی ہے اور اور کچھ نہیں کرتی۔