PPTP کی خرابی 800 اور 812 اور ایک منٹ بعد کنکشن کا ٹوٹنا

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

خرابی 800 کا مطلب ہے کہ سرنگ کبھی بنی ہی نہیں

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

اس بیرونی راستے کو اپنے LAN سے باہر سے آزمائیں، کیونکہ دفتر کے اندر کام کرنے والا کنکشن کنارے کے بارے میں کچھ ثابت نہیں کرتا:

$ nc -vz vpn.example.net 1723
Connection to vpn.example.net 1723 port [tcp/*] succeeded!
$ sudo tcpdump -ni eth0 proto gre
tcpdump: listening on eth0, link-type EN10MB

اگر 1723 جواب دے اور کلائنٹ کے جڑنے کی کوشش کے دوران کیپچر خالی رہے، تو راستہ پروٹوکول 47 گرا رہا ہے۔ ایسا راؤٹر جس میں 1723 فارورڈ ہے مگر PPTP پاس تھرو بند ہے، بالکل وہی نمونہ بناتا ہے: TCP ہینڈ شیک مکمل ہوتا ہے، پھر GRE پیکٹ غائب ہو جاتے ہیں، اس لیے ناکامی اسناد کے مسئلے جیسی لگتی ہے حالانکہ کوئی لاگ ان کوشش نہیں ہوئی۔

فارورڈنگ کو سرور کے موجودہ LAN پتے کی طرف موڑیں، جہاں راؤٹر پیش کرے وہاں PPTP پاس تھرو فعال کریں، اور اسی بیرونی مقام سے دوبارہ کوشش کریں۔ جب GRE اوپر فلٹر ہو اور آپ اسے بدل نہ سکیں، تو TCP 443 پر SSTP یا UDP 500 اور 4500 پر L2TP/IPsec کو Windows کی طرف آپ کی کسی بھی تبدیلی سے بہتر امکان ہے۔

خرابی 812 کا مطلب ہے سرور کا آپ کا تصدیق کا طریقہ مسترد کرنا

سرنگ کے اوپر آنے کے بعد خرابی 812 واپس آتی ہے، اسی لیے یہ پاس ورڈ کے مسئلے جیسی محسوس ہوتی ہے۔ سرور کنکشن کے لیے طے شدہ تصدیق کا طریقہ مسترد کرتا ہے، ضروری نہیں کہ خود پاس ورڈ۔ کلائنٹ پر VPN اندراج کھولیں، سیکیورٹی ٹیب پر جائیں، قسم کو Point-to-Point Tunneling Protocol پر رکھیں، واضح پروٹوکول فہرست منتخب کریں اور Microsoft CHAP ورژن 2 پر ٹک لگائیں۔

آپ ڈائیلاگ میں کلک کیے بغیر موجودہ ترتیب پڑھ سکتے ہیں:

$ Get-VpnConnection -Name "Office" | Select-Object -ExpandProperty AuthenticationMethod
MsChapv2

جو سرور MS-CHAP v2 مانگتا ہے وہ PAP پر یا کمزور چیز پر بات کرنے والی خودکار قسم پر چھوڑے گئے کلائنٹ کو مسترد کرتا ہے، اور خرابی کسی بھی صارف کے پاس ورڈ کی جانچ سے پہلے آتی ہے۔ اکاؤنٹ کی شکل اسی مسترد ہونے کا دوسرا نصف ہے۔ ایک معاملے میں Windows نے MicrosoftAccount\[email protected] شکل کی Microsoft اکاؤنٹ شناخت بھیجی جبکہ سرور مقامی یا ڈومین اکاؤنٹ چاہتا تھا۔ SERVERNAME\username لکھنے سے Windows کو بتایا گیا کہ کس اکاؤنٹ ذخیرے سے رجوع کرنا ہے اور خرابی ہٹ گئی۔ نام ہاتھ سے درج کریں، محفوظ اسناد کو پچھلی شکل دہرانے کی اجازت نہ دیں۔

ایک منٹ بعد ٹوٹنا ایک keepalive فیصلہ ہے

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

Linux pptpd سرور پر وہ اقدار /etc/ppp/options.pptpd میں رہتی ہیں، اور معمول کی مرمت وقفہ چھوٹا کرنا نہیں بلکہ بجٹ بڑھانا ہے:

# /etc/ppp/options.pptpd
lcp-echo-failure 30
lcp-echo-interval 5
# then
sudo systemctl restart pptpd

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

اوورلیپ ہونے والے سب نیٹ ڈیٹا راستہ توڑتے ہیں

PPTP سرنگ صاف تصدیق کر سکتی ہے اور پھر بھی کہیں نہیں پہنچ سکتی جب دونوں مقامات ایک ہی نجی رینج استعمال کریں، مثلاً دفتر اور گھر میں 192.168.1.0/24۔ کلائنٹ نہیں بتا سکتا کہ دیا گیا پتہ کس ہوسٹ کی طرف ہے، اور کچھ اسٹیک ایک منتخب کرنے کے بجائے راستہ نصب کرنے سے ہی انکار کر دیتے ہیں۔

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

اس مرحلے سے شروع کریں جو ناکام ہوا: 800 کے لیے GRE، 812 کے لیے طریقہ اور اکاؤنٹ سٹرنگ، شیڈول کے مطابق مرنے والی سرنگ کے لیے ایکو ترتیبات۔