গেটওয়ে নিজের অ্যাডমিন পৃষ্ঠা হোস্ট করে: ভেতরের ঠিকানা নাকি পাবলিক

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

পৃষ্ঠাটি বাইরে থেকে লোড হয়, টানেল দিয়ে নয়

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

গন্তব্য রুট একটি ঠিকানা বেছে নেয়, পোর্ট নয়। রাউটিং টেবিলে কিছুই জানে না যে পোর্ট 443 প্রশাসনের জন্য আর পোর্ট 1194 হলো পরিবহন, তাই দুটিকেই একই গন্তব্য হিসেবে ধরা হয়।

এজন্যই পৃষ্ঠাটি কখনো কাজ করে আর কখনো করে না, নির্ভর করে ক্লায়েন্ট কোন নাম ও কোন নেটওয়ার্ক ব্যবহার করেছে তার উপর। এটি প্রমাণীকরণের সমস্যা নয়, পথের সমস্যা. দুই ক্লায়েন্টই পুরোপুরি ভালোভাবে প্রমাণীকরণ করে।

বাইরের এন্ডপয়েন্ট পৌঁছানোর মতো রাখুন

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

ফলাফল হলো পাবলিক ঠিকানাটি ক্লায়েন্ট থেকে পৌঁছানোর মতো থাকে, তাই ওই ঠিকানায় ব্রাউজার অনুরোধও একই ব্যতিক্রম অনুসরণ করে টানেলে না ঢুকেই বেরিয়ে যেতে পারে। ব্যতিক্রমটি তার কাজ করছে, আর ক্ষতি করছে নামটি।

কিছু বদলানোর আগে ইন্টারফেস তালিকা নয়, রুটের সিদ্ধান্ত পড়ুন। নিচের কমান্ডগুলো ইনভেন্টরি নয়, সিদ্ধান্তটি ছাপে। যেই ক্লায়েন্ট ব্যর্থ হয়েছে সেখান থেকেই সেগুলো চালান।

ip -4 route get 203.0.113.77
ip -4 rule show
ip -4 route show table all

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

পরিষেবাকে একটি ব্যক্তিগত নাম দিন

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

পরিবহনের নামটি ভেতরের ঠিকানায় পুনর্নির্দেশ করবেন না, কারণ পরবর্তী টানেল স্থাপন তখন এমন ঠিকানায় পৌঁছাতে চাইবে যা কেবল একটি টানেলের ভেতরেই বিদ্যমান। ওই ভুল একটি VPN তৈরি করে যা ঠিক একবারই কাজ করে।

দুটি ঠিকানা পরিবারই যাচাই করুন, কারণ পিছনে পড়ে থাকা একটি AAAA রেকর্ড ব্রাউজারকে এমন জায়গায় পাঠাতে পারে যা ব্যক্তিগত পরিকল্পনা কখনো কভার করেনি।

dig +short admin.hq.internal
dig +short -t AAAA admin.hq.internal
curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://admin.hq.internal/

প্রক্রিয়াটি যেখানে চলে সেখানে নীতি মিলিয়ে নিন

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

হোস্ট পোর্টে প্রকাশিত একটি কনটেইনার ভিন্ন পথ অনুসরণ করে, কারণ প্যাকেটটির গন্তব্য-অনুবাদ হয় ও ফরওয়ার্ড হয়। সেই অনুরোধ হোস্টের ফরওয়ার্ডিং নীতি ও Docker-এর নিজস্ব নিয়মের মুখোমুখি হয়, এজন্যই একটি কাজ করা নেটিভ লিসেনার এমন কনটেইনারের সঙ্গে সহাবস্থান করতে পারে যা একই পোর্ট প্রত্যাখ্যান করে।

দুই ক্ষেত্রেই স্টার্টআপ ক্রম গুরুত্বপূর্ণ, কারণ এমন ঠিকানায় বাইন্ড যা কেবল টানেল ওঠার পরেই দেখা যায়, বুটের সময় নীরবে ব্যর্থ হয়।

ব্যক্তিগত প্রবেশাধিকার ও প্রত্যাখ্যাত পাবলিক পথ যাচাই করুন

অ্যাপ্লিকেশনের নিজস্ব পরিচয় যাচাই অক্ষত রেখে অনুমোদিত ক্লায়েন্ট থেকে একটি নতুন নামযুক্ত অনুরোধ করুন। তারপর টানেলের বাইরে থেকে একই পরিষেবা চেষ্টা করুন এবং নিশ্চিত করুন এটি উত্তর দেয় না। ব্যক্তিগত নাম একটি সুবিধা, বিধিনিষেধ নয়, আর পাবলিক ঠিকানায় এখনো বাঁধা লিসেনার এখনো উন্মোচিত। শেষ যাচাইটি বেশিরভাগ পর্যালোচনা বাদ দেয়।

ব্যবহারকারীরা যে হোস্টনেম পেয়েছেন তা নয়, বাইন্ডিং ও ফিল্টার অবস্থা পড়ুন। উন্মোচন সকেটের বৈশিষ্ট্য, নামের নয়। এই পার্থক্য প্রতিটি DNS পরিবর্তনেও টিকে থাকে।

ss -lntp | grep ':443'
nft list ruleset | grep -n 443
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' https://203.0.113.77/

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