opt-verify شامل کرنے سے آپ کی OpenVPN سائفر خرابی کیوں درست نہیں ہوگی

آپ کو opt-verify شامل کرنے کی تجویز ملتی ہے، آپ لائن شامل کرتے ہیں، اور سائفر خرابی ٹھیک وہیں رہتی ہے جہاں تھی۔ یہ نتیجہ متوقع ہے، کیونکہ آپشن نے کبھی سائفر پر بات چیت نہیں کی۔ یہ آپشن مطابقت کی جانچ تھی، جو 2.6 میں متروک ہوئی اور 2.7 میں ہٹائی گئی، اور اس کے ساتھ اب بھی پارس ہونے والی پروفائل نے اس سے کچھ بھی نافذ نہیں کیا۔

لائن پہلے کیا کرتی تھی یہ جاننا مددگار ہے، اس سے پہلے کہ آپ یہ نتیجہ نکالیں کہ یہی گمشدہ حصہ ہے۔ تاریخ یہ بھی بتاتی ہے کہ اب یہ مدد کیوں نہیں کر سکتی۔

آپشن پہلے کیا نافذ کرتا تھا

2.6 کا دستور opt-verify کو متروک قرار دیتا ہے اور پچھلا رویہ بیان کرتا ہے: سرور ان کلائنٹس کو خارج کر دیتا ہے جن کے اعلان کردہ آپشن اس کے اپنے سے نہیں ملتے، اور ڈیوائس کی قسم اور MTU جیسی چیزوں کا موازنہ کرتا ہے۔ وہ جانچ آپشن مطابقت کی جانچ کے فعال رہنے پر بھی منحصر ہے، اس لیے disable-occ کے ساتھ چلنے والے سرور کے پاس یہ شروع ہی سے نہیں تھی۔ غور کریں کہ موازنہ کس سے بنتا ہے: دوسری طرف کی کنفیگریشن بیان کرنے والے متن سے۔ یہ اس بارے میں کچھ نہیں کہتا کہ ڈیٹا چینل کون سا سائفر استعمال کرے گا۔

یہی پہلی وجہ ہے کہ فلیگ سائفر خرابی درست نہیں کر سکتا۔ سائفر کا انتخاب data-ciphers پالیسی اور دونوں فریقوں کی حمایت سے طے ہوتا ہے، اور متنی مطابقت کی جانچ نہ وہ فہرست بڑھاتی ہے نہ بات چیت کرتی ہے۔ دوسری وجہ دائرہ ہے: جانچ اس بارے میں ہے کہ اعلان کردہ آپشن ہم آہنگ دکھتے ہیں یا نہیں، نتیجے میں بننے والے راستے کے معیار کے بارے میں نہیں۔

2.7 لائن دیکھ کر کیا کرتا ہے

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

اس لیے پارس ہونے والی پروفائل کسی داخلے کی جانچ کے ہونے کا ثبوت نہیں۔ اگر آپ کا واحد اشارہ یہ ہے کہ کلائنٹ جڑ گیا، تو آپ نے جانا کہ نحو قبول ہو گئی۔

خرابی اصل میں کہاں رہتی ہے

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

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

صرف لائن نہیں، ارادہ بدلیں

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

تمام سائفر غیر فعال ہیں اس پرانی تجویز کا جواب ہر تاریخی الگورتھم فعال کر کے نہ دیں۔

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

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