ফোন পেজ খুলছে না: লিসেন ঠিকানাটি দেখুন

ল্যাপটপ পেজটি localhost-এ পরিবেশন করছে, ফোনটি একই VPN-এ যোগ দিয়েছে, আর ফোনের ব্রাউজার বলছে সাইটটিতে পৌঁছানো যাচ্ছে না। টানেলে এখনও কোনো ত্রুটি নেই, কারণ টানেল কেবল প্যাকেট পৌঁছে দেয়। loopback ইন্টারফেসে বাঁধা একটি ডেভেলপমেন্ট সার্ভার অন্য কোনো ঠিকানায় পাঠানো সংযোগ কখনও গ্রহণ করে না, তাই প্রথমে দেখা উচিত লিসেনিং সকেট, VPN নয়।

সকেট, বাইন্ড সেটিং, ফায়ারওয়াল নিয়ম ও URL এই ক্রমে একটির পর একটি দেখুন।

সকেট আরও সংকীর্ণ প্রশ্নের উত্তর দেয়

127.0.0.1-এ তৈরি একটি লিসেনার নিজের মেশিন থেকে আসা ট্রাফিক গ্রহণ করে এবং অন্য ঠিকানায় আসা সবকিছু প্রত্যাখ্যান করে। ওয়াইল্ডকার্ড ঠিকানার লিসেনার প্রতিটি স্থানীয় ইন্টারফেসে গ্রহণ করে, VPN ইন্টারফেসসহ, যা বেশিরভাগ ডেভেলপমেন্ট সেটআপের প্রয়োজনের চেয়ে প্রশস্ত। একটি নির্দিষ্ট VPN ঠিকানায় বাঁধা লিসেনার সবচেয়ে সংকীর্ণ কার্যকর বিকল্প, এবং এটি কেবল ততক্ষণ কাজ করে যতক্ষণ সেই ঠিকানাটি থাকে।

এর থেকে দুটি নামকরণের ফাঁদ তৈরি হয়। ফোনের ব্রাউজারে localhost মানে ফোন, ল্যাপটপ নয়। ওয়াইল্ডকার্ড ঠিকানা হলো একটি বাইন্ড মান, URL-এ টাইপ করার মতো কিছু নয়। এগুলোর যেকোনোটি দিয়ে পরীক্ষা করলে কেউ এমন ব্যর্থতা রিপোর্ট করবে যেখানে নেটওয়ার্কের কোনো ভূমিকাই ছিল না।

IPv6 তৃতীয় একটি ক্ষেত্র যোগ করে, কারণ সকেট সহজে উপেক্ষিত কিছু অপশনের উপর নির্ভর করে IPv4 ও IPv6 গ্রহণ করতে পারে। তালিকায় ঠিকানার পরিবারটি পড়ুন। এক পরিবারের জন্য ওয়াইল্ডকার্ড এন্ট্রি অন্যটিকে বর্ণনা করে না।

লিসেন ঠিকানাটি পড়ুন

কনফিগারেশন বদলানোর আগে সকেটটি দেখুন। স্থানীয় ঠিকানা, পোর্ট ও মালিক প্রসেস একসাথে বলে দেয় 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 স্থানীয় ঠিকানা প্রশ্নটির নিষ্পত্তি করে: ফায়ারওয়ালের কোনো পরিবর্তনই কাজে লাগবে না, কারণ অ্যাপ্লিকেশনটি VPN ইন্টারফেসে শুনছে না। ওয়াইল্ডকার্ড বা VPN ঠিকানা মানে সকেট ঠিক আছে এবং পরের সীমান্তটি প্রযোজ্য।

মালিক প্রসেসটিও নিশ্চিত করুন, কারণ সাধারণ পোর্টে অসম্পর্কিত কোনো সার্ভিস টেবিলটিকে সঠিক দেখাতে পারে, অথচ অভীষ্ট সার্ভারটি কখনও চালু হয়নি। কেবল নাম নয়, এক্সিকিউটেবলের পাথও মিলিয়ে দেখুন। আগের রান থেকে পড়ে থাকা প্রসেস প্রায়ই ছদ্মবেশ ধরে।

অ্যাপ্লিকেশনের মাধ্যমে বাইন্ড বদলান

ফ্রেমওয়ার্কের নথিভুক্ত লিসেন-ঠিকানা অপশন ব্যবহার করুন এবং প্রসেসটি পুনরায় চালু করুন। ল্যাপটপ যদি 10.77.0.1 ব্যক্তিগত ঠিকানার মালিক হয়, ফোনের URL হয় http://10.77.0.1:8080/ এবং সেই ঠিকানাটি VPN-এর মধ্য দিয়ে রুট করতে হবে; সেটআপে আর কিছুই বদলায় না।

বাইন্ড জোর করতে Windows-এ ইচ্ছামতো ঠিকানা যোগ করবেন না বা গেটওয়ে বদলাবেন না। সেই পরিবর্তনগুলো ডিবাগিং সেশন ছাড়িয়ে টিকে থাকে এবং পরের মানুষকে অবাক করে। VPN ঠিকানা তৈরির আগে চালু করা সার্ভারও বাইন্ড করতে ব্যর্থ হতে পারে, তাই ক্ষণস্থায়ী ইন্টারফেসের জন্য চালুর ক্রম গুরুত্বপূর্ণ। এটিকে আবার চেষ্টা করার সুযোগ দিন বা টানেলের পরে চালু করুন। বুটের সময় বাইন্ড ব্যর্থতা পরদিন সকালে ঠিক ফায়ারওয়াল সমস্যার মতো দেখায়।

HTTPS-এর জন্য সার্ভিসের হোস্টনেম ও সার্টিফিকেট যাচাই অপরিবর্তিত রাখুন। কাঁচা ঠিকানায় সার্টিফিকেট সতর্কতা একটি নামকরণ সমস্যা, ক্লিক করে এড়িয়ে যাওয়ার ধাপ নয়, আর প্রাইভেট DNS-কে আপনার বেছে নেওয়া লিসেনারের সঙ্গে মিলতে হবে।

একটি নিয়ম খুলুন, পুরো নেটওয়ার্ক নয়

VPN ঠিকানায় সকেট গ্রহণ করা শুরু করলে ফায়ারওয়াল ঠিক করে অনুরোধটি পৌঁছাবে কি না। নিয়মটিকে এই অ্যাপ্লিকেশন, এই প্রোটোকল, এই স্থানীয় পোর্ট ও অনুমোদিত দূরবর্তী উৎসে সীমাবদ্ধ করুন, এবং VPN অ্যাডাপ্টারে কোন প্রোফাইল সক্রিয় তা নিশ্চিত করুন।

Windows আসলে যে উৎস ঠিকানা দেখে সেটিই ব্যবহার করুন, গেটওয়ে যে অনুবাদ করে থাকুক তা সহ, কারণ মূল ক্লায়েন্ট ঠিকানার জন্য লেখা নিয়ম অনূদিত ঠিকানার সঙ্গে মিলবে না।

পেজ লোড হয়ে অ্যাপ্লিকেশন ত্রুটি দেখানো মানে অগ্রগতি: HTTP প্রত্যাখ্যান TCP সংযোগ না থাকার চেয়ে ভিন্ন ব্যর্থতা, আর পরের তদন্তটি নেটওয়ার্কের নয়, অ্যাপ্লিকেশনের নিজস্ব অ্যাক্সেস নীতির।

নির্দিষ্ট ফোন থেকে পেজটি চেয়ে এবং বাদ দেওয়া কোনো ডিভাইস এখনও সেখানে পৌঁছাতে পারে না তা নিশ্চিত করে শেষ করুন। সবকিছু অনুমোদন করা নিয়মসহ কাজ করা লিসেনার একই ফলাফল নয়।