Windows VPN کے پتہ والے خانے میں پورٹ صرف SSTP کے ساتھ کام کرتا ہے

ایک VPN سرور TCP 10443 پر جواب دیتا ہے، Windows کا بلٹ اِن کلائنٹ کے پاس درست اسناد ہیں، اور پھر بھی کنکشن DNS کے ٹائم آؤٹ جیسی روک کے بعد گر جاتا ہے۔ وجہ عام طور پر پتہ والا خانہ ہوتی ہے: سرور کا نام یا پتہ میں vpn.example.com:10443 لکھنے سے Windows پوری سٹرنگ کو میزبان نام کے طور پر پڑھتا ہے، کیونکہ وہ خانہ عام host:port اِدخال نہیں ہے۔ پورٹ وہاں بیان ہو سکتا ہے یا نہیں، یہ اس ٹنل کی قسم پر منحصر ہے جو پروفائل استعمال کرتا ہے، اور چار اقسام میں سے صرف ایک قدر کو ایسی چیز سمجھتی ہے جسے وہ تجزیہ کر سکے۔

پتہ والا خانہ host:port خانہ کیوں نہیں

اُس خانے کے پیچھے پروفائل کی خاصیت ServerAddress ہے اور ہر ٹنل قسم خود فیصلہ کرتی ہے کہ سٹرنگ کے ساتھ کیا کرنا ہے۔ اُن میں سے تین کے پاس بھرنے کے لیے کوئی پورٹ پیرامیٹر نہیں، اس لیے دو نقطے اور ایک عدد محض ایسے نام کے حروف ہیں جو کبھی حل نہیں ہوگا۔ چوتھا HTTPS پر چلتا ہے، جہاں پورٹ URL کا حصہ ہوتا ہے، اس لیے قدر ایسی شکل میں لکھنی ہوگی جو URL کے طور پر تجزیہ ہو۔

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

مستقل پورٹ والی تین اقسام

PPTP TCP 1723 سے جڑتا ہے اور پھر ٹنل GRE، IP پروٹوکول 47 میں لے جاتا ہے۔ L2TP/IPsec ٹنل کے لیے UDP 1701 اور IPsec کے لیے UDP 500 اور 4500 استعمال کرتا ہے، جبکہ 4500 NAT عبور کرنے کا پورٹ ہے۔ IKEv2 بھی UDP 500 اور 4500 استعمال کرتا ہے۔ اِن پروفائلز میں سے کوئی بھی انٹرفیس میں کہیں پورٹ کا خانہ ظاہر نہیں کرتا، اور کوئی بھی غیر معیاری پورٹ پر بات چیت نہیں کرے گا۔

چنانچہ کسی حسبِ ضرورت پورٹ پر سننے والا سرور اِن پروفائلز کے لیے ناقابلِ رسائی ہے، پتہ کیسے ہی لکھا جائے۔ عملی جوابات محدود ہیں: معیاری پورٹ سرور پر شائع کریں، یا معیاری پورٹ کو اُس کے آگے والے راؤٹر پر حسبِ ضرورت پورٹ میں منتقل کریں۔ دونوں کلائنٹ پروفائل کو اچھوتا چھوڑ دیتے ہیں، جو اُس وقت بہت قیمتی ہوتا ہے جب پروفائل پالیسی سے تقسیم ہو، ہاتھ سے لکھا نہ جائے۔

SSTP کو URL درکار ہے، نام نہیں

SSTP استثنا ہے کیونکہ یہ TLS نشست کے اندر چلتا ہے۔ خانے کا تجزیہ URL کے طور پر ہونا چاہیے: پہلے https:// اسکیمہ، پھر میزبان، پھر دو نقطے اور پورٹ۔ اسکیمہ کے بغیر Windows قدر کو عام نام ہی سمجھتا رہتا ہے اور کنکشن کسی بھی TLS تبادلے سے پہلے ناکام ہو جاتا ہے۔

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

Get-VpnConnection -Name "Corporate SSTP" | Select-Object Name, ServerAddress, TunnelType

ServerAddress بالکل وہی دکھاتا ہے جو محفوظ ہوا تھا۔ اگر یہ دو نقطوں والا ننگا میزبان نام پڑھا جائے تو پروفائل کو کبھی URL نہیں ملا اور کتنی ہی بار دوبارہ کوشش کرنے سے یہ درست نہیں ہوگا۔

اُسی خانے میں چپکانے والا وینڈر نحو

کچھ گیٹ ویز اُس خانے کے لیے اضافی روایات کی دستاویز کرتے ہیں، جیسے پورٹ کے بعد شامل کیا جانے والا realm یا ایسے استفساری پیرامیٹر جو سرٹیفکیٹ کے سلوک کو بدلتے ہیں۔ اُنہیں اُس وینڈر کا سرور سمجھتا ہے اور بعض بلڈز میں اُس کا اپنا کلائنٹ بھی۔ وہ Windows پروفائل فارمیٹ کا حصہ نہیں، اور اُنہیں بلٹ اِن پروفائل میں چپکانا عموماً وہی خاموش نام کی ناکامی پیدا کرتا ہے۔

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

پورٹ ثابت کریں، پھر ناکام مرحلہ پڑھیں

پروفائل کو الزام دینے سے پہلے تصدیق کریں کہ کلائنٹ کے نیٹ ورک سے کوئی چیز اُس پورٹ پر TCP قبول کرتا ہے:

Test-NetConnection vpn.example.com -Port 10443

کامیابی سننے والے کو ثابت کرتی ہے، SSTP کو نہیں۔ ویب سرور، معکوس پراکسی یا لوڈ بیلنسر TCP ہینڈ شیک مکمل کر سکتے ہیں اور پھر بھی SSTP نہ بول سکیں، اس لیے سبز ٹیسٹ اور سرخ VPN کا ملاپ حقیقی امتزاج ہے۔ سرٹیفکیٹ کے موضوع کا موازنہ پروفائل کے نام سے کریں، اور اُن بلڈز میں RasClient لاگ دیکھیں جن میں وہ شامل ہو، کیونکہ وہ عام ٹائم آؤٹ کے بجائے ناکام ہونے والا مرحلہ درج کرتا ہے۔

پھر اُس آپشن پر غور کریں جو مسئلے کو دستاویز کرنے کے بجائے دور کرتا ہے: باہر سے TCP 443 کو VPN سرور پر 10443 کی طرف بھیجیں۔ پھر کلائنٹ بغیر کسی پورٹ کے طے شدہ پروفائل استعمال کرتا ہے، جو عموماً منظم بیڑے کے لیے سب سے صاف انتظام ہوتا ہے اور حسبِ ضرورت پورٹ کو داخلی تفصیل بنا دیتا ہے۔