آپ کے URL کو 45000 نہیں، پورٹ 80 یا 443 پر داخلہ کیوں درکار ہے

براؤزر میں ہوسٹ نام لکھیں اور اسکیم منزل کا پورٹ طے کرتی ہے: http کے لیے 80، https کے لیے 443۔ DNS جواب میں کوئی چیز اسے منسوخ نہیں کرتی، اور آپ کی مشین پر کوئی فارورڈنگ اصول فراہم کنندہ کے کنارے پر سننے والا نہیں بنا سکتا۔ جب VPN فراہم کنندہ آپ کو 45000 جیسا اونچا عوامی پورٹ دیتا ہے، تو واضح URL کام کرتا ہے اور صاف نہیں۔ خلا داخلے کے مقام پر ہے، ایپلیکیشن کے اندر نہیں۔

براؤزر سے پراسیس تک کا راستہ ایک بار دیکھیں، اور تینوں اشاعتی اختیار پراسرار لگنا بند کر دیں گے۔

دیکھیں درخواست واقعی کہاں جاتی ہے

براؤزر نام کو پتے میں حل کرتا ہے، پھر اگر URL کوئی دوسرا پورٹ نہ بتائے تو اسکیم کے طے شدہ پورٹ پر اس پتے سے جڑتا ہے۔ آنے والے کنکشن کا کیا ہوگا یہ آپ کے فراہم کنندہ کا کنارہ طے کرتا ہے۔ اگر اس کی فارورڈنگ جدول صرف 45000 کو آپ کے اندرونی پتے سے منسلک کرتی ہے، تو 80 پر کنکشن کے پاس جانے کی کوئی جگہ نہیں اور آپ کی مشین شامل ہونے سے پہلے ہی اسے مسترد یا چھوڑ دیا جاتا ہے۔

یہ انکار کنارے پر ہوتا ہے، اسی لیے آپ کی ایپلیکیشن کے لاگ کچھ نہیں دکھاتے۔ لاگ نہ ہونا اس بات کا ثبوت ہے کہ پیکٹ کہاں رکا، اس بات کا نہیں کہ ایپلیکیشن خراب ہے۔

کوئی مقامی اصول کنارے کو کیوں درست نہیں کر سکتا

ایپلیکیشن ہوسٹ پر ری ڈائریکٹ یا DNAT اصول پہلے سے آئے ہوئے پیکٹوں پر اثر انداز ہوتا ہے۔ فراہم کنندہ پر پورٹ 80 کو بھیجے گئے پیکٹ کبھی نہیں پہنچتے، اس لیے اصول کا کبھی جائزہ نہیں لیا جاتا۔ پورے مسئلے میں یہ سب سے عام ضائع ہونے والا گھنٹہ ہے۔

DNS بھی پورٹ نہیں اٹھا سکتا۔ HTTP کی تفصیل اسکیم کے طے شدہ اقدار متعین کرتا ہے، اور A یا AAAA ریکارڈ پتہ واپس کرتا ہے جبکہ CNAME کوئی دوسرا نام واپس کرتا ہے۔ براؤزر پھر بھی اسکیم کا پورٹ جوڑتا ہے، اس لیے صرف URL میں واضح پورٹ ہی منزل بدلتا ہے۔

پہلا اختیار: واضح پورٹ رکھیں

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

وہاں رہتے ہوئے ری ڈائریکٹ اور کوکی کی حد جانچیں، کیونکہ اپنا ہوسٹ نام Location ہیڈر میں لکھنے والا بیک اینڈ یہ بندوبست منسوخ کر دیتا ہے۔

دوسرا اختیار: طے شدہ پورٹ پر حقیقی داخلہ حاصل کریں

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

ملکیت اور دستیابی کی تحریری تصدیق کریں، جس میں یہ بھی شامل ہو کہ جب ٹنل کسی دوسرے پتے کے ساتھ دوبارہ جڑتی ہے تو داخلے کا کیا ہوتا ہے۔ ٹنل کے ساتھ چلنے والا داخلہ ایسی رکاوٹیں پیدا کرتا ہے جو DNS ناکامیوں جیسی لگتی ہیں۔

تیسرا اختیار: سامنے فرنٹ اینڈ رکھیں

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

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

ایک ہی اصل رکھیں

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

پھر سامعین کو ذہن میں رکھ کر فیصلہ کریں۔ مختصر URL منظم فرنٹ اینڈ کا جواز بن سکتا ہے، اور صرف VPN کے لیے بنی نجی سروس کو غلطی سے عوامی بنانا مناسب نہیں۔