PPTP/MS-CHAPv2 کو ریٹائر کرنا: پرانے VPN کے لیے رن بک

ہر ماہ بدلے جانے والے اور تجوری میں رکھے جانے والے بیس حروف کے پاس ورڈ MS-CHAPv2 چلانے والے PPTP سرور کو جدید VPN نہیں بنا دیتے۔ پاس ورڈ ایسی ادل بدل کا ان پٹ ہے جس کی کمزوری خود ادل بدل میں ہے۔ یہ رن بک اس کے لیے ہے جسے وہ سرور وراثت میں ملا ہے اور اسے اس پر منحصر سائٹ کاٹے بغیر صارفین کو وہاں سے ہٹانا ہے۔ مراحل ترتیب سے کریں، کیونکہ ہر ایک ایک ریکارڈ چھوڑتا ہے جو اس وقت درکار ہوگا جب کوئی پوچھے کہ رسائی اچانک کیوں بدلی۔

کسی چیز کو چھونے سے پہلے اسٹیک لکھیں

PPTP کے لفظ میں تین تہیں یکجا ہوتی ہیں اور ہر ایک اپنے انداز میں ناکام ہوتی ہے۔ ٹنل خود PPTP ہے، GRE کے ساتھ TCP 1723۔ تصدیق وہ PPP طریقہ ہے جو سرور پیش کرتا ہے، یہاں MS-CHAPv2۔ لنک کا تحفظ MPPE ہے جس کی چابیاں اسی تصدیق کی ادل بدل سے نکلی ہیں۔ تینوں کے نام لینے سے بعد کی درستی غلط تہہ پر نہیں اترتی۔

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

grep -RniE 'mschap|mppe|require-mppe' /etc/ppp/options.pptpd /etc/pptpd.conf
ss -lntp 'sport = :1723'
journalctl -u pptpd -n 40 --no-pager

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

Get-VpnAuthProtocol
netstat -ano | findstr :1723

فیصلہ کریں کہ آج ٹنل واقعی کیا ڈھو رہی ہے

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

پھر پوچھیں کہ جو حملہ آور لاگ اِن کی ادل بدل دیکھ سکتا ہے یا اس پر اثر ڈال سکتا ہے اسے کیا ملے گا۔ MS-CHAPv2 کے ساتھ جواب میں وہ مواد شامل ہے جو صارف کا پاس ورڈ آف لائن بحال کرنے دیتا ہے، اور اسی لیے لمبائی اور گردش ڈیزائن کو درست نہیں کرتے: بحال شدہ راز ہر اس نظام پر معتبر ہے جہاں صارف نے اسے دوبارہ استعمال کیا۔

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

نہ مختصر دوپہر کا وقفہ نہ کم صارف تعداد کسی خفیہ نگاری کی خصوصیت کو پالیسی کی خصوصیت نہیں بناتی۔

منتقلی ایک ہی دیکھ بھال کی کھڑکی میں کریں

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

sudo systemctl disable --now pptpd
sudo ss -lntp | grep -E ':(1723|1194|51820)\b'
sudo nft list ruleset | grep -i gre

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

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

تصدیق کریں کہ بدل وہ کام کرتا ہے جو PPTP کرتا تھا

چیک لسٹ یہ نہیں کہ «جڑتا ہے کیا»۔ یہ ہے کہ تصدیق، پتہ تقسیم، DNS حل، راستہ انتخاب، دوبارہ جڑنے کا رویہ اور ہم منصب کی تصدیق سب بدل کے تحت قائم ہیں یا نہیں۔ ہر ایک کو پائلٹ ڈیوائس پر، اسی ترتیب سے جانچیں، اور دیکھا گیا نتیجہ توقع کے ساتھ لکھیں۔

ip -4 addr show tun0
ip route get 198.51.100.23
resolvectl query intranet.example.net

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

دوبارہ جڑنا سب سے آخر میں جانچیں، کیونکہ وہیں زیادہ تر بدل پیچھے ہٹتے ہیں: لیپ ٹاپ کو سلا دیں، نیٹ ورک بدلیں، اور تصدیق کریں کہ ٹنل پرانے راستے چھوڑے بغیر دوبارہ قائم ہو جاتی ہے۔

واپسی، منسوخی اور وہ ریکارڈ جو آپ چھوڑتے ہیں

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

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

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