PPTP جڑتا ہے اور پھر Linux NAT کے پیچھے لٹک جاتا ہے: GRE مددگار

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

فارورڈنگ کبھی مسئلہ نہیں تھی

پورٹ فارورڈنگ کا قاعدہ TCP یا UDP ٹریفک بیان کرتا ہے۔ یہ ایسے پے لوڈ کی وضاحت نہیں کر سکتا جو سیشن کے بیچ میں دوسرے IP پروٹوکول پر چلا جائے، اور PPTP بالکل یہی کرتا ہے۔

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

کنٹرول کے لیے TCP، ڈیٹا کے لیے GRE

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

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

PPTP کے بغیر ننگا GRE ایسی دوبارہ تحریر کا محتاج نہیں، اسی لیے سادہ GRE سرنگ ایسے راؤٹر سے گزر سکتی ہے جو اسی راستے پر PPTP کلائنٹ کے لیے ناکام ہوتا ہے۔

چار ماڈیولز اور ایک sysctl جس نے انہیں بند کیا

دو ماڈیولز فریمنگ سنبھالتے ہیں، nf_conntrack_proto_gre اور nf_nat_proto_gre۔ مزید دو کال شناخت کنندہ سنبھالتے ہیں، nf_conntrack_pptp اور nf_nat_pptp۔ آخری کو لوڈ کرنے سے باقی انحصار کے ذریعے آ جاتے ہیں، اس لیے ماڈیول فہرست میں چاروں دکھنے چاہئیں۔

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

ان کا لوڈ ہونا اب کافی نہیں۔ Linux 4.7 سے net.netfilter.nf_conntrack_helper sysctl بطور طے شدہ 0 ہے، جو نئے فلو کے لیے خودکار مددگار تفویض بند کر دیتا ہے۔ راؤٹر میں ہر ماڈیول ہو سکتا ہے اور پھر بھی کچھ ترجمہ نہ ہو۔ دوبارہ ماڈیول فہرست دیکھنے سے پہلے مؤثر قدر چیک کریں۔

یا تو خودکار تفویض دوبارہ عالمی طور پر آن کریں، یا مددگار کو ضرورت مند فلو سے جوڑیں اور باقی سب کو ویسا ہی رہنے دیں:

iptables -t raw -A PREROUTING -p tcp --dport 1723 -j CT --helper pptp

دوسرا آپشن ترجیحی ہے۔ یہ پورے راؤٹر پر خودکار تفویض دوبارہ چالو کرنے کے بجائے رویے کو PPTP ٹریفک تک محدود کرتا ہے۔

بغیر پورٹ کے پروٹوکول کھولنا

1723 کی اجازت دینے والا فائر وال قاعدہ پروٹوکول 47 کے بارے میں کچھ نہیں کہتا۔ firewalld پر کلائنٹ کی طرف والے زون میں پروٹوکول کی اجازت دیں۔ سادہ iptables پر ان پٹ چین میں gre پروٹوکول قبول کریں۔

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

جڑنے کے بعد سائز کی حد

GRE ہیڈر شامل کرتا ہے، اور اس کے اندر کا PPP مزید شامل کرتا ہے، اس لیے کام کرنے والا لنک 1500 سے کافی کم MTU بتاتا ہے۔ چھوٹے جواب لوڈ ہوتے ہیں اور بڑے لٹک جاتے ہیں، جو پہلی مسئلہ حل ہوتے ہی نمودار ہونے والی دوسری، غیر متعلق مسئلے جیسا لگتا ہے۔

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

راستہ درست کرنے سے صارف کام پر واپس آتا ہے، اور اس سے PPTP اچھا انتخاب نہیں بنتا۔ MS-CHAPv2 اور RC4 بہت پہلے متروک ہو چکے ہیں، اس لیے ماڈیول لوڈ کرنے کو عارضی اصلاح سمجھیں اور برقرار رکھے گئے پروٹوکول کی طرف جانے کا منصوبہ بنائیں۔