ہاٹ اسپاٹ کے ذریعے PPTP: TCP 1723 صرف آدھا ہے

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

GRE IP پروٹوکول 47 ہے۔ یہ TCP یا UDP پورٹ 47 نہیں ہے، اور یہی فرق فائر وال کے بارے میں زیادہ تر الجھن کی وضاحت کرتا ہے۔

دو راستے، ایک کنکشن

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

ترجمہ اپنی شرط جوڑتا ہے۔ پورٹ شیئر کرنے والے گیٹ وے کو اکثر PPTP سمجھنے والے ALG کی ضرورت ہوتی ہے تاکہ کال شناخت کنندگان کو پتوں کے ساتھ دوبارہ لکھا جا سکے، اور اس کے بغیر والا سیشن کو پیکٹ ضائع ہونے جیسا دکھنے والے انداز میں خراب کر سکتا ہے۔ یہ رویہ عام ہے لیکن عمل درآمد پر منحصر ہے، اس لیے کسی بھی وینڈر کی حد کو ہر ہاٹ اسپاٹ کی خصوصیت نہیں، مثال سمجھیں۔

ہاٹ اسپاٹ دو اور حدیں شامل کرتا ہے

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

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

807 کو فیصلہ نہیں، رکاوٹ کے طور پر پڑھیں

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

ہاٹ اسپاٹ پر کامیاب براؤزر ٹیسٹ صرف یہ ثابت کرتا ہے کہ ایک عام ایپلیکیشن راستہ کام کرتا ہے۔ یہ GRE کے بارے میں کچھ نہیں کہتا۔

ناکام مرحلے کو الگ کریں

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

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

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