SECLEVEL=0 علامت کا علاج کرتا ہے، سند کا نہیں

OpenVPN کنکشن ناکام ہوتا ہے، کوئی ایک سطر کی درستی تلاش کرتا ہے جو SECLEVEL=0 شامل کرتی ہے، اور سرنگ بلند ہو جاتی ہے۔ جو بدلا وہ سند نہیں تھی اور نہ ہی سائفر سیٹ؛ لائبریری بھر میں قبولیت کی حد سرک گئی، اور اس کے بعد عمل جو کچھ کرتا ہے وہ نیا دائرہ وراثت میں پاتا ہے۔ یہی سطر ماحول کے ہر پروفائل میں کاپی ہونے سے پہلے یہ سمجھنا ضروری ہے۔

مقرر کریں کہ کون سی لائبریری اور کون سی پالیسی نافذ ہے

SECLEVEL OpenSSL کا تصور ہے، اس لیے پہلا سوال یہ ہے کہ کیا آپ کا بلڈ OpenSSL استعمال کرتا ہے۔ OpenVPN کو ایک سے زیادہ کرپٹوگرافی لائبریریوں سے منسلک کیا جا سکتا ہے، اور ان میں سے ایک پر لاگو ترتیب باقی کے لیے بے معنی ہے۔ بائنری سے پوچھیں کہ یہ کس چیز سے بنی، پھر لائبریری سے پوچھیں کہ اس نے کون سا ورژن اور ترتیب لوڈ کی:

openvpn --version | head -3
openssl version -a

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

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

مسترد ہو سکنے والی تین چیزوں کو الگ کریں

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

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

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

ان پٹ بدلیں، حد نہیں

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

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

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

اگر کم کرنا ہی پڑے تو دائرہ محدود کریں اور درج کریں

کبھی کبھی منظور شدہ مطابقت کا استثنا ہی درست جواب ہوتا ہے، خاص طور پر ایسے پرانے ساتھی کے لیے جس کی ریٹائرمنٹ کا منصوبہ تاریخ شدہ ہو۔ اسے پورے ہوسٹ کے بجائے اسی خدمت تک محدود کریں جسے اس کی ضرورت ہے: خدمت کے لیے مخصوص ترتیب فائل یا مخصوص OpenSSL ترتیب کا اثر عالمی پروفائل میں ایکسپورٹ سے کم ہوتا ہے۔

استثنا کے ساتھ چار چیزیں لکھیں: درست ترتیب، اسے منظور کرنے والا مالک، متاثرہ کلائنٹ، اور وہ شرط جس کے تحت یہ ہٹایا جائے گا۔ ریٹائرمنٹ شرط کے بغیر استثنا عارضی جواز کے ساتھ منسلک مستقل کمزوری ہے۔

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

پھر شناخت اور تحفظ کی تصدیق کریں

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

openssl x509 -in /etc/openvpn/client.crt -noout -subject -dates -text | grep -E 'Signature Algorithm|Public-Key'
openvpn --show-tls | head -20

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

آڈٹ سے گزرنے والی حوالگی بتاتی ہے کہ کس پالیسی نے کون سا ان پٹ مسترد کیا، کیا بدلا، اور نتیجے میں کیا قابل قبول رہتا ہے۔ „یہ SECLEVEL=0 کے ساتھ کام کرتا ہے“ ایک کنکشن کے بارے میں مشاہدہ ہے، تعیناتی کا سیکیورٹی جائزہ نہیں۔