OpenVPN کنٹرول پیکٹ کی ٹریسنگ: TLS سے پہلے tls-auth

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

لفافہ اسی ترتیب سے پڑھیں جس میں بنتا ہے

کنٹرول پیکٹ سیشن شناخت، اختیاری tls-auth HMAC، تکرار اور توثیق کی معلومات، اور قابلِ اعتماد پیغام شناخت رکھتا ہے، اور اس کے بعد پیغام قسم کا پایا لوڈ آتا ہے۔ جب پیغام ہینڈ شیک پیغام ہو، پایا لوڈ TLS خفیہ متن ہوتا ہے۔ پورا تعلق یہی ہے: TLS مواد ایسے پیغام کے اندر سفر کرتا ہے جسے لفافہ پہلے ہی محفوظ رکھتا ہے۔ دیکھیں OpenVPN نیٹ ورک پروٹوکول حوالہ جو کنٹرول چینل کے فیلڈز اسی ترتیب سے درج کرتا ہے۔

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

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

دکھائیں کہ جانچ ہینڈ شیک سے پہلے ہوتی ہے

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

ڈیمون کی تفصیل بڑھائیں اور tun آلے کے بجائے کنٹرول چینل دیکھیں:

openvpn --config /etc/openvpn/server.conf --verb 6

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

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

دونوں سروں پر کلید، سمت اور digest ملا کر رکھیں

تین قدریں متفق ہونی چاہئیں اور ان میں سے صرف ایک فائل ہے۔ مستقل کلید کا مواد دونوں سروں پر یکساں ہونا چاہیے، سمت مخالف ہونی چاہیے، اور HMAC کے لیے استعمال ہونے والا digest مطابق ہونا چاہیے۔ کلید کے مواد کو چھونے سے پہلے ترتیب چیک کریں، کیونکہ ایک الٹی سمت خراب فائل سے زیادہ ناکامیوں کی وضاحت کرتی ہے:

grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf

مشترکہ راز ایڈیٹر کے بجائے آلے سے بنائیں، اور اجازتیں تنگ رکھیں:

openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key

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

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

ٹیگ صرف حقیقی فارمیٹ سے دوبارہ بنائیں

بائٹ کے لحاظ سے عین مطابق دوبارہ پیداوار VPN چلانے سے الگ کام ہے، اور یہ صرف حقیقی ان پٹ کے ساتھ چلتا ہے: پیکٹ بنانے والا عمل درآمد اور ورژن، منتخب digest، سمت، اور سیشن شناخت اور توثیق صف سمیت حقیقی بائٹس۔ فیلڈ فہرست کی متنی پیشکش وہ بائٹس نہیں ہیں۔

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

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

تحفظ ہٹائے بغیر عدم مطابقت واپس لیں

پرکشش امتحان یہ ہے کہ tls-auth حذف کریں، کنکشن کامیاب ہوتے دیکھیں اور یہ نتیجہ نکالیں کہ کلید غلط تھی۔ وہ جواب آپ کو تحفظ کا نقصان پہنچاتا ہے اور یہ نہیں سکھاتا کہ تین میں سے کون سی قدر مطابق نہیں تھی۔ اس کے بجائے سرور کی طرف سے منظور شدہ مطابق ترتیب لیں اور اس سے موازنہ کریں۔

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

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