কেন আপনার URL-এ পোর্ট 80 বা 443 এন্ট্রি দরকার, 45000 নয়

ব্রাউজারে একটি হোস্টনেম টাইপ করুন এবং স্কিমটি গন্তব্য পোর্ট ঠিক করে: 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-এর জন্য একটি ব্যক্তিগত পরিষেবাকে ভুল করে পাবলিক বানানো উচিত নয়।