PPTP پر LCP ہم منصب نے ختم کیا: پہلے MPPE فعال کریں

لنک تصدیق سے گزرتا ہے، کلائنٹ جڑے ہونے کی اطلاع دیتا ہے، اور ایک سیکنڈ بعد لاگ LCP ہم منصب نے ختم کیا کے ساتھ بند ہو جاتا ہے۔ یہ سطر GRE سرنگ کے اندر PPP مذاکرات سے آتی ہے، یعنی ٹرانسپورٹ پہلے ہی کام کر رہا تھا اور دونوں سرے لنک کے اختیارات پر متفق نہیں تھے۔ یہاں پاس ورڈ اور سرور پتے عام طور پر بے قصور ہوتے ہیں۔ سب سے پہلے موازنہ کرنے والی چیز انکرپشن پالیسی ہے، اور Linux پر pppd کی ہم منصب فائل پہلی جگہ ہے جہاں دیکھنا چاہیے۔

LCP ناکامی PPP مرحلے کے بارے میں کیا بتاتی ہے

PPTP، PPP کو GRE کے اندر لپیٹتا ہے: TCP 1723 کنٹرول کنکشن کال تیار کرتا ہے، GRE پے لوڈ اٹھاتا ہے، اور پھر LCP تصدیقی پروٹوکول، کمپریشن اور MPPE جیسے اختیارات پر بات کرتا ہے۔ جب کوئی لازمی اختیار اس کی طرف ناقابل قبول ہو تو ہم منصب LCP ختم کر دیتا ہے۔ ایسا لاگ جس میں CHAP یا MSCHAPv2 کا تبادلہ مکمل ہو اور فوراً بعد LCP ختم ہو جائے، پالیسی کی نامنظوری ہے، رسائی کی ناکامی نہیں۔ اگر سرنگ مذاکرات تک پہنچتی ہی نہیں، تو LCP سطر پڑھنے سے پہلے pppd اور اس کا پلگ ان جانچیں۔

دو پیشگی شرطیں آسانی سے رہ جاتی ہیں۔ pppd بائنری موجود ہونی چاہیے، اور ہم منصب فائل میں نامزد PPTP پلگ ان نصب ہونا چاہیے؛ پیکیج نہ ہو تو کوئی بھی اختیار زیر بحث آنے سے پہلے ڈائل ختم ہو جاتا ہے۔

MPPE کو اسی طرف فعال کریں جو اس کا تقاضا کرتی ہے

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

pty "pptp vpn.example.net --nolaunchpppd"
name alice
remotename PPTP
require-mppe-128

ڈائل سے پہلے ماڈیول modprobe ppp_mppe کے ذریعے لوڈ کریں، کیونکہ اس کے بغیر require-mppe-128 ناکام ہوتا ہے۔ Windows پر مساوی کنٹرول VPN اندراج کا سیکیورٹی ٹیب ہے، جہاں کلائنٹ کو سرور کی پیشکش قبول کرنے کے بجائے انکرپشن کا تقاضا کرنے کو کہا جانا چاہیے۔ اگر سرور پھر بھی LCP ختم کرتا ہے، تو اس کے آپریٹر سے پوچھیں کہ MPPE لازمی، اختیاری یا غیر فعال ہے، کیونکہ کلائنٹ ایسی حفاظت پر مذاکرات نہیں کر سکتا جسے سرور مسترد کرے۔ پیغام کے غائب ہونے کے لیے انکرپشن بند کرنا غلط سمت ہے: یہ اس پروٹوکول کی واحد حفاظت ہٹا دیتا ہے۔

ترمیم سے پہلے کام کرنے والی ہم منصب فائل محفوظ کریں۔ غلط ٹائپ شدہ require-mppe سطر وہی عام LCP ناکامی دوبارہ پیدا کرتی ہے اور آپ کو شروع پر واپس بھیجتی ہے۔

ایپلیٹ کی بجائے pppd کا اپنا لاگ پڑھیں

ڈیسک ٹاپ ایپلیٹس قطعِ رابطہ دکھاتے ہیں اور وجہ چھپاتے ہیں، اس لیے ایک کوشش کے بارے میں ڈیمون کی روایت پڑھیں۔ systemd نظاموں میں پیغام جرنل میں جاتا ہے؛ پرانی ترتیبیں روایتی لاگ فائلوں میں لکھتی ہیں۔

journalctl --since "10 min ago" | grep -i -E "pppd|lcp|mppe"
tail -n 50 /var/log/syslog

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

دوبارہ کنیکشن میں اصلاح برقرار رکھیں: ہک نام اور MTU

لنک قائم رہنے کے بعد دو تفصیلیں طے کرتی ہیں کہ یہ دوبارہ کنیکشن برداشت کرے گا یا نہیں۔ ہک /etc/ppp/ip-up.d اور /etc/network/if-up.d میں رہتے ہیں، اور دونوں ڈائریکٹریاں run-parts پر کارروائی کرتا ہے، جس کا فائل نام فلٹر نقطہ رکھنے والا ہر نام مسترد کرتا ہے۔ اسی لیے set-pptp.sh نامی اسکرپٹ چھوڑ دیا جاتا ہے، جبکہ set-pptp چلایا جاتا ہے۔ اسکرپٹ کے مندرجات کو ڈیبگ کرنے سے پہلے نام جانچیں، پھر اسی ہک کے اندر سے چھوٹا MTU مقرر کریں تاکہ ہر نیا ppp انٹرفیس دستی کمانڈ کے بغیر اسے ورثے میں پائے۔

run-parts --test /etc/ppp/ip-up.d
ip link set dev ppp0 mtu 1200

سیشن کو دانستہ ختم کرنے کے لیے پروسیس ناموں کے پیٹرن ملاپ کے بجائے pppd کے ریکارڈ کردہ pid کو نشانہ بنائیں، کیونکہ ppp رکھنے والی ہر چیز کو مارنا غیر متعلقہ لنک بھی توڑ دیتا ہے۔ PPTP متروک ہے اور MS-CHAPv2 کمزور ہے، اس لیے ان جانچوں کو ایسے لنک کی دیکھ بھال سمجھیں جو چلتا رہنا چاہیے، نئی جگہ PPTP تعینات کرنے کی وجہ کے طور پر نہیں۔