auth ڈائجسٹ کون سے OpenVPN پیکٹوں کی حفاظت کرتا ہے؟
auth اختیار پروفائل کے اشارے سے کم احاطہ کرتا ہے۔ ڈائجسٹ پالیسی مقرر کرنے سے پہلے چینل، AEAD کی صورت اور کنٹرول چینل کا تحفظ دیکھیں۔
OpenVPN ڈائجسٹوں کے بارے میں بیشتر بحث غلط پیکٹ سے شروع ہوتی ہے۔ auth SHA256 کو ”صرف وہی ساتھی قبول کریں جو SHA256 پیش کرتے ہیں“ کے طور پر پڑھنا پہلی چیز ہے جسے بھلانا ہے۔ یہ اختیار مخصوص پیکٹوں کے لیے ایک ڈائجسٹ کا نام دیتا ہے، اور وہ پیکٹ کون سے ہیں یہ چینل پر اور اس بات پر منحصر ہے کہ وہ چینل AEAD ہے یا نہیں۔ نیچے دیے گئے چار سوالات ترتیب سے دیکھیں؛ ہر ایک یہ محدود کرتا ہے کہ یہ ترتیب آپ کی تعیناتی میں کیا معنی رکھ سکتی ہے۔
اس چینل کا نام لیں جسے ترتیب نے محفوظ کرنا ہے
OpenVPN میں ایک کنٹرول چینل ہے جو TLS مصافحے کی ٹریفک لے جاتا ہے اور ایک ڈیٹا چینل ہے جو ٹنل کا پے لوڈ لے جاتا ہے۔ auth ڈائجسٹ دونوں میں کردار ادا کرتا ہے، مگر ایک جیسا نہیں، اور پروفائل فرق کو شاذ و نادر ہی نمایاں کرتا ہے۔ کنفگ فائل چھونے سے پہلے لکھیں کہ آپ دونوں میں سے کسے محدود کرنا چاہتے ہیں۔
نیچے دیا گیا جدول اسی اختیار کے ہر سیاق میں پہنچنے کا مختصر ورژن ہے۔
| Context | What the auth digest does |
|---|---|
| Data channel without AEAD | Selects the HMAC digest that authenticates each data packet |
| Data channel with AEAD, such as GCM | Unused for the data channel; the cipher authenticates its own packets |
| Control channel protected by tls-auth | Selects the HMAC digest for that protection, even when data is AEAD |
اس پر انحصار کرنے سے پہلے جانچیں کہ ڈیٹا چینل AEAD ہے یا نہیں
اگر طے شدہ ڈیٹا سائفر AES-GCM یا CHACHA20-POLY1305 ہے تو ڈیٹا چینل خود اپنی تصدیق کرتا ہے اور الگ ڈائجسٹ وہ کام نہیں کرتا جو آپ شاید سوچ رہے ہیں۔ دونوں AEAD ساختیں ہیں، اس لیے سالمیت اسی عمل سے پیدا ہوتی ہے جو پے لوڈ کو خفیہ کرتا ہے۔ یہ کوئی درجہ گراوٹ نہیں، مگر اس کا مطلب ہے کہ ”ہر ڈیٹا پیکٹ HMAC-SHA256 ہے“ کے جواز والی پالیسی اس ٹنل پر حقیقتاً غلط ہے۔ پالیسی دوبارہ لکھنے سے پہلے سرور لاگ یا کلائنٹ کی حالت کی آؤٹ پٹ میں طے شدہ قدر کی تصدیق کریں۔
پروفائل کی فہرست کے بجائے وہ سائفر دیکھیں جو واقعی طے ہوا، کیونکہ مذاکرات مجموعے کے کسی دوسرے رکن پر جا سکتے ہیں۔ data-ciphers AES-256-GCM:AES-128-GCM ایک مذاکراتی فہرست ہے، اور دونوں اندراجات AEAD ہیں، اس لیے ان میں سے کوئی بھی پے لوڈ کے تحفظ کے لیے auth ڈائجسٹ استعمال نہیں کرتا۔
کنٹرول چینل کے تحفظ کو الگ فیصلہ سمجھیں
tls-auth کنٹرول چینل کے پیکٹوں میں HMAC شامل کرتا ہے اور اپنا ڈائجسٹ auth ترتیب سے لیتا ہے، اسی لیے AEAD ٹنل میں بھی بامعنی ڈائجسٹ مرتب ہو سکتا ہے۔ tls-crypt اپنے مقررہ تحفظ والی الگ ترتیب ہے، اس لیے یہ نہ سمجھیں کہ یہ tls-auth کی ہر خوبی ورثے میں لیتا ہے۔ مفروضوں کو ایک دوسرے پر منتقل کرنے کے بجائے اپنے منتخب کردہ طریقے کی دستاویزات پڑھیں۔
دونوں ساتھیوں کو ترتیب اور کلید کی سمت پر بھی متفق ہونا چاہیے۔ ملتا جلتا ڈائجسٹ مگر غلط سمت میں استعمال شدہ کلید فائل ایسا مصافحہ بناتی ہے جو ایسے اسباب سے ناکام ہوتا ہے جنہیں ڈائجسٹ ترتیب بیان نہیں کر سکتی۔
auth کو سائفر مذاکرات اور سرٹیفکیٹس سے الگ رکھیں
تین ترتیبات مسلسل گڈمڈ کی جاتی ہیں: auth ڈائجسٹ، ڈیٹا سائفر کی فہرست اور سرٹیفکیٹ کا دستخطی الگورتھم۔ پہلی کو بدلنے سے سرٹیفکیٹ دوبارہ جاری نہیں ہوتا، اس کا دستخطی ڈائجسٹ منتخب نہیں ہوتا، اور صارف-پاس ورڈ طریقہ قائم نہیں ہوتا۔ پروٹوکول اختیارات کی تعریفیں OpenVPN 2.6 کے ماخذوں میں ہر ایک کو اس کے اپنے حصے میں بیان کرتی ہیں، جو یاد دہانی ہے کہ یہ آزاد بٹن ہیں۔
ڈائجسٹ کی تبدیلی کے بعد جب ساتھی جڑنے سے انکار کرے تو سبب عموماً باقی دو ترتیبات میں سے ایک میں عدم مطابقت ہوتا ہے۔ کوئی بھی بدلنے سے پہلے دونوں سرے پڑھیں۔
پالیسی لکھیں اور چلتی ہوئی کنفگ سے اس کا موازنہ کریں
بیڑے کی سطح کا بیان ایک ہی جملے میں اجازت یافتہ ڈیٹا چینل طریقوں اور منتخب کنٹرول چینل تحفظ کا واضح تذکرہ کرے۔ وہ جملہ قابلِ جانچ ہے؛ ”ہم SHA256 استعمال کرتے ہیں“ نہیں۔ پھر اس کا موازنہ ذخیرے کے سانچے سے نہیں، بلکہ مؤثر سرور اور کلائنٹ پروفائلز سے کریں۔
ہر ٹنل نے واقعی کس بات پر اتفاق کیا اور کس طریقے نے اس کے پیکٹوں کی تصدیق کی، یہ درج کر کے اختتام کریں۔ پروفائل میں نظر آنے والی auth سطر صرف کنفگریشن کے ارادے کا ثبوت ہے، اور ارادہ جانچ کا سب سے سستا حصہ ہے۔