فون صفحہ نہیں کھول سکتا: سننے کا پتہ جانچیں

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

socket، bind کی ترتیب، firewall کا قاعدہ اور URL اسی ترتیب سے دیکھیں۔

socket ایک زیادہ تنگ سوال کا جواب دیتا ہے

127.0.0.1 پر بنایا گیا سننے والا خود مشین سے آنے والا ٹریفک قبول کرتا ہے اور کسی دوسرے پتے پر آنے والی ہر چیز رد کرتا ہے۔ wildcard پتے پر سننے والا ہر مقامی انٹرفیس پر قبول کرتا ہے، بشمول VPN انٹرفیس، جو زیادہ تر ڈویلپمنٹ سیٹ اپ کی ضرورت سے زیادہ وسیع ہے۔ ایک مخصوص VPN پتے سے منسلک سننے والا سب سے تنگ مفید آپشن ہے، اور یہ صرف اسی وقت تک کام کرتا ہے جب تک وہ پتہ موجود ہو۔

اس سے دو نام رکھنے کے جال نکلتے ہیں۔ فون کے براؤزر میں localhost کا مطلب فون ہے، لیپ ٹاپ نہیں۔ wildcard پتہ bind کی قدر ہے، URL میں ٹائپ کرنے کی چیز نہیں۔ جو بھی ان میں سے کسی ایک سے جانچ کرے گا وہ ایسی ناکامی بتائے گا جس میں نیٹ ورک کبھی شامل ہی نہیں تھا۔

IPv6 تیسرا کیس جوڑتا ہے، کیونکہ socket آسانی سے نظر انداز ہونے والے اختیارات کے مطابق IPv4 اور IPv6 قبول کر سکتا ہے۔ فہرست میں پتے کا خاندان پڑھیں۔ ایک خاندان کے لیے wildcard اندراج دوسرے کی وضاحت نہیں کرتا۔

سننے کا پتہ پڑھیں

ترتیب بدلنے سے پہلے socket کا معائنہ کریں۔ مقامی پتہ، پورٹ اور مالک عمل مل کر بتاتے ہیں کہ سرور VPN سے قابل رسائی ہے یا نہیں۔

Get-NetTCPConnection -State Listen -LocalPort 8080 | Select-Object LocalAddress,LocalPort,OwningProcess
Get-Process -Id (Get-NetTCPConnection -State Listen -LocalPort 8080).OwningProcess
ipconfig | Select-String -Pattern 'IPv4'
Get-NetFirewallRule -DisplayName '*8080*' | Format-Table DisplayName,Enabled,Profile,Direction,Action

127.0.0.1 کا مقامی پتہ سوال طے کر دیتا ہے: firewall کی کوئی تبدیلی مدد نہیں کرے گی، کیونکہ ایپلیکیشن VPN انٹرفیس پر نہیں سن رہی۔ wildcard یا VPN پتہ اس کا مطلب ہے کہ socket ٹھیک ہے اور اگلی حد لاگو ہوتی ہے۔

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

bind کو ایپلیکیشن کے ذریعے بدلیں

فریم ورک کے دستاویزی سننے والے پتے کا آپشن استعمال کریں اور عمل دوبارہ شروع کریں۔ اگر لیپ ٹاپ کے پاس نجی پتہ 10.77.0.1 ہے تو فون کا URL http://10.77.0.1:8080/ بن جاتا ہے اور وہ پتہ VPN کے ذریعے روٹ کرنا ہوگا؛ سیٹ اپ میں اور کچھ نہیں بدلتا۔

bind پر مجبور کرنے کے لیے Windows میں من مانی پتے شامل نہ کریں اور گیٹ وے نہ بدلیں۔ وہ تبدیلیاں ڈیبگنگ سیشن کے بعد بھی رہتی ہیں اور اگلے شخص کو حیران کرتی ہیں۔ VPN پتے کے وجود سے پہلے شروع کیا گیا سرور بھی bind ہونے میں ناکام ہو سکتا ہے، اس لیے عارضی انٹرفیس کے لیے شروع کرنے کی ترتیب اہم ہے۔ اسے دوبارہ کوشش دیں یا سرنگ کے بعد شروع کریں۔ بوٹ کے وقت bind کی ناکامی اگلی صبح بالکل firewall کے مسئلے جیسی نظر آتی ہے۔

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

ایک قاعدہ کھولیں، پورا نیٹ ورک نہیں

جب socket VPN پتے پر قبول کرے تو firewall فیصلہ کرتا ہے کہ درخواست پہنچتی ہے یا نہیں۔ قاعدے کو اس ایپلیکیشن، اس پروٹوکول، اس مقامی پورٹ اور مجاز دور دراز ماخذ تک محدود کریں، اور تصدیق کریں کہ VPN اڈاپٹر پر کون سا پروفائل فعال ہے۔

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

لوڈ ہو کر ایپلیکیشن کی خرابی دکھانے والا صفحہ پیش رفت ہے: HTTP کا رد ہونا TCP کنکشن نہ ہونے سے مختلف ناکامی ہے، اور اگلی تحقیق نیٹ ورک کی نہیں، ایپلیکیشن کی اپنی رسائی پالیسی کی ہے۔

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