OpenVPN tls-ciphersuites بمقابلہ tls-version-min: ہر ایک کیا نافذ کرتا ہے

زیادہ تر OpenVPN TLS بحثوں میں تین مختلف حقائق ایک ہی سطر میں سمو دیے جاتے ہیں: آپ کا کلائنٹ بلڈ کیا کر سکتا ہے، پروفائل کیا اجازت دیتا ہے اور سیشن نے دراصل کیا طے کیا۔ مختصر TLS 1.3 سوٹ فہرست درمیانی سوال کا صرف آدھا جواب دیتی ہے، اور پروٹوکول ورژن کی نچلی حد کے بارے میں کچھ نہیں کہتی۔ نیچے دی گئی جانچیں ترتیب سے کریں اور پہلی ناکام جانچ پر رک جائیں، کیونکہ ہر اگلی جانچ یہ مانتی ہے کہ پچھلیاں طے ہو چکی ہیں۔

کوئی بھی فہرست پڑھنے سے پہلے بلڈ کی جانچ کریں

کنفیگریشن ہدایت کسی ایسی بائنری میں پروٹوکول سپورٹ شامل نہیں کر سکتی جس میں وہ نہ ہو۔ ورژن بینر سے شروع کریں، جو کمپائل شدہ کرپٹو لائبریری کا نام بتاتا ہے:

openvpn --version

OpenSSL سے منسلک 2.6 بلڈ tls-cipher اور tls-ciphersuites دونوں قبول کرتا ہے۔ mbed TLS والے بلڈ میں TLS 1.3 سوٹ کا انتخاب بالکل نہیں ہے، اور 2.6 دستی tls-ciphersuites کو OpenSSL آپشن کے طور پر نشان زد کرتا ہے۔ اگر سرور کسی اور بیک اینڈ کے ساتھ دوبارہ بنایا جائے تو وہی پروفائل کنفیگریشن کی ایک بھی سطر بدلے بغیر اپنا رویہ بدل سکتا ہے۔

یہاں ہوتے ہوئے openvpn --show-tls چلائیں اور آؤٹ پٹ محفوظ رکھیں۔ یہی وہ فہرست ہے جس سے آپ بعد میں موازنہ کریں گے، اور کسی کے پروفائل ترمیم کرنا شروع کرنے سے پہلے اسے پکڑ لینا سستا ہے۔

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

ورژن کی حدیں سائفر فہرستوں سے الگ رکھیں

2.6 دستی میں یہ ایک نہیں، تین کنٹرول ہیں:

• tls-cipher TLS 1.2 اور اس سے پہلے کے لیے سائفر پالیسی مقرر کرتا ہے اور OpenSSL کی سائفر فہرست کو دیا جاتا ہے؛
• tls-ciphersuites TLS 1.3 سوٹ منتخب کرتا ہے؛
• tls-version-min اور tls-version-max ان پروٹوکول ورژنوں کو محدود کرتے ہیں جو کنکشن استعمال کر سکتا ہے۔

اس لیے احتیاط سے تراشی گئی TLS 1.3 سوٹ فہرست اس بات پر کچھ ثابت نہیں کرتی کہ پرانا ورژن اب بھی اجازت یافتہ ہے۔ اگر ضرورت «صرف TLS 1.3» ہے تو اسے ورژن کی نچلی حد اٹھاتی ہے، اور سوٹ فہرست صرف اسی حد کے اندر انتخاب تنگ کرتی ہے:

tls-version-min 1.3
tls-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

یہ جوڑا دو کام کرتا ہے۔ ایک سطر مٹانے سے دوسری آپ کی سوچ سے کم نافذ کرتی ہے، اور یہی وہ ناکامی ہے جس کو پکڑنے کے لیے یہ پوری جانچ موجود ہے۔

ڈیٹا چینل چوتھا کنٹرول ہے۔ data-ciphers سرنگ کے اندر ہم آہنگ سائفر پر بات چیت کرتا ہے، اور اس کا نتیجہ کنٹرول چینل کے TLS ورژن کے بارے میں کچھ نہیں کہتا۔ سیشن خلاصے میں AES-256-GCM دیکھنا کسی بھی سمت میں TLS 1.3 کا ثبوت نہیں ہے۔

show-tls کو مقامی فہرست کے طور پر پڑھیں

--show-tls ان سوٹوں کی فہرست دیتا ہے جنہیں وہ کرپٹو لائبریری سپورٹ کرتی ہے جس سے یہ بائنری منسلک ہے، ترجیحی ترتیب میں۔ یہ گیٹ وے کی رپورٹ نہیں ہے۔ دستی واضح طور پر کہتا ہے کہ فہرست مقامی لائبریری سے آتی ہے، یعنی OpenSSL 3.x والا لیپ ٹاپ اور پرانے بلڈ والا راؤٹر ایک ہی سرور سے بات کرتے ہوئے مختلف فہرستیں چھاپیں گے۔

فرض کریں کہ کلائنٹ A، B اور C سوٹ سپورٹ کرتا ہے اور ایک سیشن B منتخب کرتا ہے۔ اس سے یہ ثابت نہیں ہوتا کہ سرور A یا C کی اجازت دیتا ہے، اور نہ یہ کہ B اس کا واحد اجازت یافتہ انتخاب ہے۔ تینوں سطریں الگ رکھیں، اور زیادہ تر الجھی ہوئی TLS بحثیں خود ہی حل ہو جائیں گی۔

فہرست رکھنا پھر بھی مفید ہے۔ جب سیشن ناکام ہو تو لائبریری کی فہرست کا پروفائل کی فہرست سے موازنہ بتاتا ہے کہ کلائنٹ کو سرور کی مطلوبہ چیز پیش کرنے کا کوئی موقع تھا یا نہیں۔ یہ یہ بھی دکھاتا ہے کہ کسی بیک اینڈ تبدیلی نے پرانے کلائنٹس کے بھروسے والے مجموعے سے TLS_CHACHA20_POLY1305_SHA256 کو خاموشی سے ہٹا دیا یا نہیں — اسی قسم کی پسپائی جو چند صارفین کے جڑ نہ پانے کی صورت میں ظاہر ہوتی ہے جبکہ باقی سب کو کچھ پتہ نہیں چلتا۔

گیٹ وے سے ایسی بات پوچھیں جس کا وہ جواب دے سکے

اگر آپ خدمت کا انتظام کرتے ہیں تو ڈسک پر پڑی فائل کے بجائے چل رہے نمونے کی مؤثر کنفیگریشن دیکھیں۔ OpenVPN کسی اور --config راستے کے ساتھ شروع ہوا ہو سکتا ہے، انکلوڈ کھینچتا ہو، اور ترمیم کے بعد دوبارہ شروع نہ کیا گیا ہو۔ چل رہے ڈیمان کی پالیسی وہی ہے جس سے کلائنٹس ملتے ہیں۔

اگر آپ اس کا انتظام نہیں کرتے تو آپریٹر سے معاون کلائنٹ تقاضے یا محدود قبولیت جانچ مانگیں۔ مسترد کوشش خود بخود مسترد سوٹ نہیں ہے: ورژن کی نچلی حد، remote-cert-tls جیسی سند شناخت جانچ، یا tls-auth اور tls-crypt کے درمیان عدم مطابقت سوٹ کے انتخاب کے اہم ہونے سے پہلے ہی تبادلہ ختم کر سکتی ہے۔ کلائنٹ کی فہرست بدلنے سے پہلے سرور کی خرابی پڑھیں، کیونکہ «handshake failed» چار مختلف وجوہات کو محیط ہے اور ان میں سے صرف ایک سائفر عدم مطابقت ہے۔

VPN پورٹ کی طرف openssl s_client نشانہ بنانا بھی سوال کی نقل نہیں کرتا۔ کنٹرول چینل OpenVPN کے اپنے فریمنگ کے اندر چلتا ہے، اس لیے خام TLS جانچ ایسی پورٹ پر مختلف پروٹوکول آزماتی ہے جو کچھ اور متوقع رکھتی ہے۔ اس سے نکالا گیا کوئی بھی نتیجہ جانچ کے بارے میں ہے، سرنگ کے بارے میں نہیں۔

دو نتائج درج کریں اور انہیں الگ رکھیں

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

openvpn --config office.ovpn --verb 4 2>&1 | tee session.txt

پھر وہ دو سطریں یادداشت سے نہیں، اسی فائل سے پڑھیں۔ جوڑا ہی ثبوت ہے؛ صرف سوٹ نام ایک ترجیح ہے، اور ورژن کی حد اس بارے میں الگ بیان ہے کہ سرور کیا مسترد کرتا ہے۔

جانچیں اسی ترتیب سے کریں۔ --version سے بلڈ اور بیک اینڈ کی تصدیق کریں۔ کچھ بھی بدلنے سے پہلے --show-tls پکڑیں۔ مطلوبہ ورژن نچلی حد سوٹ فہرست سے الگ بتائیں۔ چل رہے نمونے کی مؤثر پالیسی اس کے مالک کے ساتھ تصدیق کریں۔ ایک اجازت یافتہ سیشن اور، اگر منصوبہ اجازت دے، پرانے ورژن کے ساتھ ایک مسترد کوشش کا مشاہدہ کریں۔ کنٹرول چینل اور ڈیٹا چینل کے نتائج الگ مشاہدات کے طور پر درج کریں۔

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