pptpd پر GRE لکھنے کی ناکامی پاس ورڈ کا مسئلہ نہیں

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

دو پیغامات، دو مختلف خرابیاں

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

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

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

پروٹوکول 47 پورٹ 47 نہیں ہے

PPTP کال قائم کرنے کے لیے TCP 1723 اور پے لوڈ لے جانے کے لیے GRE استعمال کرتا ہے۔ GRE ایک IP پروٹوکول 47 ہے، پورٹ نمبر نہیں، اس لیے پورٹ 47 کھولنے والا فائر وال اصول کچھ بھی مفید اجازت نہیں دیتا۔

راستے میں موجود راؤٹر کو PPTP passthrough خصوصیت یا GRE کی واضح اجازت درکار ہے۔ اس کے بغیر TCP ہینڈ شیک مکمل ہو جاتا ہے اور ٹنل کبھی پیکٹ نہیں لے جاتی، جو اوپر کی پڑھنے کی ناکامی ہی پیدا کرتا ہے۔ فائر وال میں پورٹ 47 کے اصول اس پروٹوکول میں سب سے زیادہ ضائع ہونے والی دوپہر ہیں۔

کون سا فریق ٹریفک گرا رہا ہے اس کا اندازہ لگانے کے بجائے سرور پر دونوں سمتوں کو ایک ساتھ دیکھیں: tcpdump -ni any port 1723 or proto gre۔

اگر 1723 کال کے قیام کو دکھاتا ہے اور GRE خاموش رہتا ہے تو رکاوٹ میزبان سے اوپر ہے۔ اگر GRE آتا ہے اور ڈیمون پھر بھی ناکام ہوتا ہے تو مسئلہ مقامی ہے اور اختیارات اگلے دیکھنے کی جگہ ہیں۔

GRE کی اجازت وہاں دیں جہاں میزبان واقعی آگے بھیجتا ہے

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

سرور کو ہی بھیجے گئے پیکٹوں کے لیے input اصول شامل کریں، کیونکہ forward زنجیر انہیں نہیں دیکھتی۔ پھر کنکشن کی کوشش سے پہلے اور بعد میں اصول کے کاؤنٹر دیکھیں، جو بتاتا ہے کہ پیکٹ آتے بھی ہیں یا نہیں۔

ہر ری بوٹ کے بعد دوبارہ چلانے کے بجائے تقسیم کی فائر وال سروس کے ذریعے اصول کو مستقل بنائیں۔ nftables میزبان پر input اور forward دونوں زنجیروں میں ip protocol gre ملائیں۔

یقینی بنائیں کہ ppp_generic ماڈیول بھی لوڈ ہے، اور جانچیں کہ کنکشن ٹریکنگ واپسی کی سمت گرا رہی ہے یا نہیں۔ دونوں فائر وال کے مسئلے جیسی لیکن نہ ہونے والی ناکامیاں پیدا کرتے ہیں۔ غائب کرنل ماڈیول جانچنے تک بالکل بلاک شدہ پروٹوکول جیسا دکھتا ہے۔

اختیارات کو اس کلائنٹ سے ملائیں جو واقعی آپ کے پاس ہے

دوسری رپورٹ کی اصلاح /etc/ppp/pptpd-options میں ہے، جہاں ترکیب PAP، CHAP اور MSCHAP کو مسترد کرتی ہے، متعلقہ require سطروں کو تبصرہ کرتی ہے اور حالت والا MPPE رکھتی ہے۔ وہ ترکیب ایک کلائنٹ مرکب کے لیے لکھی گئی تھی، اور آنکھ بند کر کے نقل کرنا عام صورت کو توڑ دیتا ہے۔ مسترد کرنے والی سطروں کو سفارش کے طور پر نہیں بلکہ اس بیان کے طور پر پڑھیں کہ مصنف کے پاس کون سے کلائنٹ تھے۔

Windows کلائنٹ کو عام طور پر MS-CHAPv2 کے ساتھ MPPE-128 درکار ہوتا ہے۔ وہ تقاضے رکھیں اور صرف وہ اختیارات ہٹائیں جن پر کلائنٹ واقعی بات چیت نہیں کر سکتا۔

# keep encryption; drop only what this client cannot negotiate
refuse-pap
refuse-chap
refuse-mschap
mppe-stateful
require-mschap-v2
require-mppe-128

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

کلائنٹ کا غلطی نمبر پڑھیں

کلائنٹ کا عددی کوڈ سرور لاگ سے زیادہ تیزی سے مرحلہ محدود کرتا ہے۔ کچھ اور پڑھنے سے پہلے اسے پڑھیں۔ 691 کا مطلب اسناد مسترد ہوئیں، 721 کا مطلب سرور نے کبھی جواب نہیں دیا، اور 619 کا مطلب کنکشن ٹوٹ گیا۔ نمبر کے ساتھ دو منٹ ترتیبات کے ساتھ ایک گھنٹہ بچاتے ہیں۔

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

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