PPTP passthrough غائب ہے: Windows VPN کی خرابی 807 کی مرمت

TCP 1723 فارورڈ کرنا اکثر PPTP کے صرف پہلے حصے کو درست کرتا ہے اور باقی کو ٹوٹا ہوا چھوڑ دیتا ہے، اسی لیے کوشش پر Windows اب بھی خرابی 807 لوٹاتا ہے۔ اگلا خیال پورٹ 47 کے لیے قاعدہ شامل کرنا ہوتا ہے، اور یہی وہ مرحلہ ہے جو ایک دوپہر ضائع کرتا ہے: GRE دراصل IP ہیڈر میں پروٹوکول نمبر ہے، کوئی ایسی پورٹ نہیں جسے فارورڈنگ ٹیبل ملا سکے۔ جب تک روٹر پروٹوکول 47 کو گزرنے نہ دے اور اسے اسی کال سے نہ جوڑے، ٹنل شروع نہیں ہو سکتا۔ نیچے کے حصے دونوں چینل الگ کرتے ہیں، پھر انہیں ایک ایک کر کے جانچتے ہیں۔

پورٹ ٹیبل میں پروٹوکول نمبر کے لیے کوئی قطار نہیں ہوتی

PPTP دو گفتگوؤں کا استعمال کرتا ہے جو مختلف طریقوں سے ناکام ہوتی ہیں۔ TCP 1723 والی کال شروع کرتی ہے، لنک کی معلومات پہنچاتی ہے اور جب صارف منقطع ہوتا ہے تو اسے توڑ دیتی ہے۔ پے لوڈ کا حصہ GRE کے اندر چلتا ہے، جسے IP ہیڈر پروٹوکول نمبر 47 سے نشان زد کرتا ہے، اور اسی ٹنل کے اندر PPP لنک پر بات کرتا ہے جبکہ MS-CHAPv2 اسناد کی جانچ کرتا ہے۔

چونکہ GRE کوئی ٹرانسپورٹ ہیڈر نہیں رکھتا، اس لیے یہ کوئی پورٹ سامنے نہیں لاتا، لہٰذا پورٹوں کے لیے لکھے گئے قاعدے کے پاس ملانے کو کچھ نہیں ہوتا۔ 1723 فارورڈ کرنے والا روٹر اس TCP سیشن کے لیے نقشہ بناتا ہے اور وہیں رک جاتا ہے۔ دوسرے نصف کو سنبھالنے والا فرم ویئر اس خصوصیت کو PPTP passthrough یا PPTP ALG کہتا ہے، اور بعض فرم ویئر دونوں میں سے کوئی نہیں دیتے اور اس خلا کا کبھی ذکر نہیں کرتے۔ چیک باکس کا لیبل اس سے کم اہم ہے کہ پروٹوکول 47 کو کسی بھی طرح پہچانا جاتا ہے یا نہیں۔

ڈیٹا کا راستہ مرنے پر Windows کیا بتاتا ہے

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

پاس ورڈ کو چھونے سے پہلے ٹرانسپورٹ پر کام کریں۔ 807 کے پیچھے بھاگتے ہوئے اسناد بدلنا اصل نقص کو اپنی جگہ رہنے دیتا ہے اور اگلی کوشش کو پڑھنا مشکل بنا دیتا ہے۔

دوسرا کلائنٹ چلتی ہوئی ٹنل کیوں توڑتا ہے

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

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

ثابت کریں کہ کون سا نصف ناکام ہو رہا ہے

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

Test-NetConnection vpn.example.com -Port 1723
rasdial "Work VPN"

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

tcpdump -ni any proto 47

Wireshark میں اس کا متبادل ڈسپلے فلٹر ip proto 47 ہے، جسے shell میں آرام نہ رکھنے والے شخص کے حوالے کرنا آسان ہے۔ GRE آئے اور جواب میں کچھ باہر نہ جائے تو مطلب واپسی کے راستے کی مرمت درکار ہے۔

خرابی کو واقعی کیا درست کرتا ہے

جہاں روٹر ترتیب سامنے لاتا ہے وہاں PPTP passthrough فعال کریں، یا جس فرم ویئر میں قواعد قبول ہوتے ہیں اس پر پروٹوکول 47 کی واضح اجازت دیں۔ RouterOS پر forward قاعدہ پروٹوکول سے براہ راست ملتا ہے، جو پورٹ پر مبنی فارورڈنگ کبھی نہیں کر سکتی۔ صارفین کا فرم ویئر عموماً وہی فیصلہ چیک باکس کے پیچھے چھپاتا ہے، بعض اوقات پورٹ فارورڈنگ کے بجائے سیکیورٹی ترتیبات کے تحت۔ ایسا کنٹرول نہ ہو تو کلائنٹ پر کچھ بھی اس کی تلافی نہیں کرتا۔

/ip firewall filter add chain=forward protocol=gre action=accept
/ip firewall filter print where protocol=gre

PPTP کو بدل دینا دوسرا آپشن ہے اور اکثر سستا بھی۔ جو روٹر خود VPN ختم کرتا ہے وہ اندر آنے والے کلائنٹس کے لیے دوہرے NAT سے بچتا ہے، اور جس پروٹوکول کو پورٹ پر مبنی NAT پہلے ہی سنبھالتا ہے اسے passthrough کی ضرورت ہی نہیں: UDP پر OpenVPN، TCP 443 پر SSTP، یا NAT-T کے ساتھ L2TP/IPsec جو ESP کو UDP 4500 میں لپیٹتا ہے۔ PPTP کا انحصار MS-CHAPv2 پر بھی ہے، جس کی دستاویزی کمزوریاں خرابی دور ہونے کے بعد بھی اسے نئی تنصیب کے لیے برا انتخاب بناتی ہیں۔

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