گھریلو راؤٹر کے پیچھے PPTP سرور: پہلے 1723 اور GRE درست کریں

گھریلو راؤٹر کے پیچھے PPTP دو غیر متعلق طریقوں سے ناکام ہوتا ہے، اور انہیں آپس میں ملانا پوری شام ضائع کر دیتا ہے۔ ایک خرابی فارورڈنگ میں خلا ہے: راؤٹر TCP 1723 گزرنے دیتا ہے اور IP پروٹوکول 47 پھینک دیتا ہے، اس لیے کلائنٹ خرابی 619 پر اٹکا رہتا ہے۔ دوسری سائز کا مسئلہ ہے: ٹنل اوپر آتا ہے، تصدیق ہوتی ہے، اور پھر پوری سائز کا پیکٹ گزرنے پر جم جاتا ہے۔ یہ جاننا کہ ان میں سے کون سی آپ کے پاس ہے پہلا حقیقی قدم ہے؛ باقی اس بات کا موازنہ کرتا ہے کہ آپ کا راؤٹر کیا بیان کر سکتا ہے، نہ کہ کون سا برانڈ بہتر ہے۔

دو کیریئر، اور صرف ایک کے پاس پورٹ ہے

PPTP دو کیریئروں میں بٹتا ہے: TCP 1723 پر کنٹرول کنکشن، اور توسیع شدہ GRE میں لپٹے PPP فریم، یعنی IP پروٹوکول 47۔ GRE کے پاس پورٹ نمبر نہیں ہے، اس لیے پورٹ 1723 فارورڈ کے طور پر لکھا گیا قاعدہ اسے ڈھانپ نہیں سکتا، ویب انٹرفیس اس فیلڈ کو جو بھی نام دے۔ گھریلو راؤٹر عام طور پر پروٹوکول قاعدے کی بجائے PPTP پاس تھرو کے نام سے چیک باکس دیتا ہے، اور وہ چیک باکس دو کام کرتا ہے: فائر وال سے پروٹوکول 47 گزرنے دیتا ہے اور NAT کو GRE بہاؤ پر نظر رکھنا سکھاتا ہے۔ لینکس راؤٹر پر یہ کام الگ ماڈیول اور الگ قواعد ہیں، اسی لیے آدھا ترتیب شدہ پاس تھرو بھی کام کرنے والا کنٹرول چینل دیتا ہے۔ کچھ بدلنے سے پہلے معلوم کریں کہ کون سا آدھا موجود ہے۔

سرور کی اپنی فائر وال کو بھی راؤٹر کے پتے سے پروٹوکول 47 کی اجازت دینی چاہیے۔ صرف 1723/tcp قبول کرنے والی ہوسٹ فائر وال LAN کے اندر سے خرابی 619 دوبارہ پیدا کرتی ہے، جس سے ٹوٹی ہوئی فارورڈنگ اور ٹوٹا ہوا ہوسٹ قاعدہ ایک جیسے دکھتے ہیں۔

sudo iptables -S FORWARD | grep -i gre
sudo nft list ruleset | grep -i gre
lsmod | grep -E 'nf_conntrack_proto_gre|nf_nat_proto_gre'

اگر ماڈیول نہیں ہیں تو انہیں sudo modprobe nf_conntrack_proto_gre nf_nat_proto_gre سے لوڈ کریں اور لوڈنگ کو مستقل کریں، کیونکہ مددگار بھول جانے والا ری بوٹ کام کرتی ٹنل کو دوبارہ خرابی 619 بنا دیتا ہے۔ فارورڈنگ قاعدے کو پروٹوکول 47 صرف سرور کے پتے کی طرف قبول کرنا چاہیے، پورا LAN نہیں۔ RFC 2637 کی تعریف کنٹرول اور ڈیٹا راستے کو الگ کرتی ہے، اس لیے کوئی ایک پورٹ فارورڈ اسکرین PPTP کو مکمل طور پر بیان نہیں کرتی۔

پاس تھرو چیک باکس یا واضح پروٹوکول قاعدہ

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

1723 کے لیے منزل NAT قاعدے میں بھی ملکیت کا مسئلہ ہے۔ اگر پرانا قاعدہ اب بھی 1723 اس ہوسٹ کو بھیجتا ہے جس نے سرور چلانا بند کر دیا، پیکٹ بند پورٹ پر گرتے ہیں اور راؤٹر کی اپنی PPTP سروس جواب دینا بند کر دیتی ہے، جو فائر وال کی ناکامی پڑھی جاتی ہے مگر حقیقت میں پرانا ہدف ہے۔ دوسرا شامل کرنے سے پہلے قاعدہ اور اس کی منزل پڑھیں۔ جو راؤٹر خود PPTP ختم کرتے ہیں، وہاں WAN قاعدہ بلٹ اِن سروس سے مقابلہ کرتا ہے، اس لیے 1723 اور پروٹوکول 47 کے لیے ایک ہی مالک چنیں۔

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

راؤٹر کو الزام دینے سے پہلے ٹنل ناپیں

PPTP مفید پے لوڈ کم کرتا ہے، اور یہ کمی ریاضی ہے، کوئی معمہ نہیں۔ ہر ٹنل پیکٹ بیرونی IP ہیڈر، توسیع شدہ GRE ہیڈر، PPP ہیڈر اور انکرپشن کے ساتھ MPPE ہیڈر لے کر چلتا ہے۔ جب راستہ بننے والا فریم نہیں لے جا سکتا، چھوٹے پیکٹ گزر جاتے ہیں، لاگ ان مکمل ہوتا ہے، اور فائل منتقلی یا TLS ہینڈ شیک پہلی بار پوری سائز کا پیکٹ بھیجنے پر سیشن رک جاتا ہے۔

اندازہ لگانے کی بجائے عدد شمار کریں۔ توسیع شدہ GRE 8 بائٹ، PPP 4 بائٹ، MPPE 4 بائٹ، اور بیرونی IP ہیڈر 20 بائٹ لیتا ہے، اس لیے ٹنل کسی بھی پے لوڈ سے پہلے 36 بائٹ کھا جاتا ہے۔ 1492 پر ختم ہونے والے PPPoE WAN پر سب سے بڑا PPP MTU جو سماتا ہے 1492 منفی 36 ہے، یعنی 1456۔ PPP اختیارات میں mtu اور mru کو اس قدر پر مقرر کریں اور بغیر تقسیم کے پنگ سے دوبارہ جانچیں۔

ping -M do -s 1464 198.51.100.7
grep -E '^(mtu|mru)' /etc/ppp/options.pptpd

پنگ راستہ ناپتا ہے، ٹنل نہیں: 1464 بائٹ پے لوڈ اور 28 بائٹ IP و ICMP ہیڈر مل کر 1492 بائٹ کا فریم بالکل بھر دیتے ہیں۔ اگر وہ پنگ ناکام ہو تو عدد کم کرتے جائیں جب تک گزر نہ جائے، پھر نتیجے سے 36 تفریق کریں۔ راستے کی حد سے اوپر مقرر ٹنل MTU سائز کا ذکر کرنے والی ایک بھی لاگ لائن کے بغیر جمود پیدا کرتا ہے۔

ایک ہی راؤٹر پر PPTP، L2TP/IPsec یا OpenVPN

ایک ہی راؤٹر تین عام ٹنلوں میں سے کوئی بھی لے جا سکتا ہے، اور فرق یہ ہے کہ اسے کیا بیان کرنا ہے۔ PPTP کو دو مختلف تہوں میں دو قواعد چاہیے۔ IPsec پر L2TP کو کلید کے تبادلے کے لیے UDP 500 اور 4500 چاہیے اور اگر NAT-T اسے نہ لے جائے تو پے لوڈ کے لیے پروٹوکول 50 چاہیے۔ OpenVPN کو ایک UDP پورٹ کافی ہے اور کوئی مددگار نہیں چاہیے۔

L2TP کا کالم خود بخود GRE سے زیادہ دوستانہ نہیں ہے۔ ESP IP پروٹوکول 50 ہے اور اس کا بھی پورٹ نہیں، اس لیے پروٹوکول 47 سے دقت رکھنے والے راؤٹر کو اسی وجہ سے پروٹوکول 50 سے بھی دقت ہو سکتی ہے۔ NAT-T ESP کو UDP 4500 کے اندر لپیٹنے کے لیے ہے، اور جب دونوں سرے حمایت کریں تو پروٹوکول 50 کا قاعدہ غیر ضروری ہو جاتا ہے۔ یہ سروں کی خصوصیت ہے، راؤٹر کے PPTP چیک باکس کی نہیں۔ دونوں کے لیے قواعد لکھنے سے پہلے تصدیق کریں کہ کلائنٹ نے واقعی کون سی انکیپسولیشن طے کی ہے۔

OpenVPN راؤٹر کی طرف سب سے کم حرکت کرنے والے حصوں والا اختیار ہے۔ ایک UDP پورٹ، ایک فارورڈنگ، کوئی کنکشن ٹریکنگ مددگار نہیں اور کال شناخت کنندگان کی کوئی دوبارہ تحریر نہیں۔ سودا یہ ہے کہ بلٹ اِن ڈائلر کی بجائے نصب کرنے والا کلائنٹ چاہیے، اور اکثر یہی واحد وجہ ہے کہ PPTP گفتگو میں رہتا ہے۔

کیا درست کرنا ہے اور کیا بدلنا ہے

فارورڈنگ اور MTU درست کرنے سے کام کرنے والی ٹنل ملتی ہے، رکھنے کے قابل نہیں۔ PPTP کی MSCHAPv2 تصدیق برسوں سے حملے کے قابل ہے، اور کام کرنے والی ٹنل وہ اسناد منتقل کرتی ہے جو آف لائن بحال ہو سکتی ہیں۔ اگر دور کا آلہ L2TP/IPsec یا OpenVPN چلا سکتا ہے تو مرمت کو تاریخ والا عارضی اقدام سمجھیں۔

فیصلہ اس پر ہے کہ دور کا سرا کیا حمایت کرتا ہے اور بندوبست کتنی دیر چلنا چاہیے۔ صرف PPTP بولنے والا پرانا آلہ مرمت پاتا ہے؛ جو کچھ کلائنٹ نصب کر سکے وہ منتقل ہوتا ہے۔

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