vpnc کمزور سائفر کی غلطی: گیٹ وے پالیسی یا ڈیسک ٹاپ مرمت؟

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

بہت مختلف اثرات والی دو مرمتیں

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

پیکیج کی تصدیق پہلی قربانی ہے: /usr/sbin/vpnc پر موجود فائل جو اب اپنے پیکیج سے مطابقت نہیں رکھتی، معمول کے سیکیورٹی اپ ڈیٹ کو تحقیقات میں بدل دیتی ہے۔ پھر اپ گریڈ یا تو خاموشی سے ریپر پر لکھ دیتے ہیں یا لاگو ہونے سے انکار کرتے ہیں، یہ اس پر منحصر ہے کہ پیکیج مینیجر تبدیل شدہ فائلوں کو کیسے برتاؤ کرتا ہے۔ دونوں میں سے کوئی نتیجہ کنکشن لاگ میں ظاہر نہیں ہوتا، اسی لیے پہلے واقعے تک ریپر کا طریقہ کشش رکھتا ہے۔ پروفائل میں ایک لائن اس بائنری سے کہیں زیادہ آسانی سے ملتی اور ہٹائی جاتی ہے جسے کسی کو تبدیل کرنا یاد نہیں۔

پرانا سوئچ واقعی کیا کرتا ہے

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

مرمت منتخب کرنے سے پہلے ناکامی کا مرحلہ پڑھیں۔ مسترد شدہ تجویز اور مسترد شدہ پاس ورڈ ملتے جلتے فرنٹ اینڈ پیغامات دیتے ہیں لیکن بالکل مختلف شواہد دیتے ہیں۔

محدود استثنا کہاں ہونا چاہیے

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

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

بات چیت کی جانچ کریں، صرف سبز آئیکن نہیں

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

vpnc --version
vpnc --print-config /etc/vpnc/legacy.conf
dpkg -V vpnc
grep -n -E 'weak|1des|no-encryption' /etc/vpnc/legacy.conf

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

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