CGNAT পোর্ট ব্লক করলে VPS দিয়ে হোম সার্ভার প্রকাশ করা

আমি বাইরে থেকে শুরু করেছি, যেভাবে একজন ব্যবহারকারী করতেন: নামটি মোবাইল ডেটায় ফোনের ব্রাউজারে লিখে দেখলাম সংযোগ সময় শেষ হওয়া পর্যন্ত ঝুলে আছে। নামটি রিজলভ হচ্ছিল, অর্থাৎ DNS ঠিক ছিল। বাড়ির রাউটারের পোর্ট-ফরওয়ার্ডিং পৃষ্ঠাও বন্ধ গলি ছিল, কারণ তার WAN ঠিকানা 100.64.31.42 দেখাচ্ছিল, আর এটি এমন ঠিকানা নয় যেখানে কোনো প্রদানকারী আমাকে ইন্টারনেট থেকে পাঠাবেন। এই সংখ্যাটিই পুরো ত্রুটি ব্যাখ্যা করে: লাইনটি carrier-grade NAT-এর পিছনে, তাই টানেলের আমার দিকের সার্বজনীন ঠিকানা প্রদানকারীর। এরপর আমি সেই আটকে থাকা ট্যাব থেকে উত্তরদাতা সেবা পর্যন্ত যে পথ হেঁটেছি তা দেওয়া হলো।

ক্লায়েন্ট থেকে শুরু করুন এবং ভেতরের দিকে এগোন

কোনো নিয়ম বদলানোর আগে প্রমাণ করুন শৃঙ্খল কোথায় থামে। ল্যাপটপে আমি dig +short files.example.net চালালাম এবং VPS-এর ঠিকানা ফেরত পেলাম, যা আমার মেশিনে পুরনো DNS বাদ দিল। তারপর curl -v --connect-timeout 5 files.example.net:5022 প্রত্যাখ্যাত হওয়ার বদলে সময় শেষে আটকে গেল। এই পার্থক্য গুরুত্বপূর্ণ: সময় শেষ হওয়া সাধারণত বোঝায় প্যাকেট পথে ফেলা হচ্ছে, আর প্রত্যাখ্যান বোঝায় কিছু একটা উত্তর দিয়ে না বলেছে।

ভেতরের দিকে পরের ধাপ ছিল VPS নিজেই। ss -ltnp 5022-এ শোনার মতো কিছু দেখাল না, যা DNAT নিয়ম তৈরির আগে প্রত্যাশিত ছিল। একই মেশিনে wg show (বা OpenVPN-এর জন্য ip -br a show tun0) নিশ্চিত করল যে বাড়ির peer সক্রিয় এবং তার handshake তাজা। peer কাজ না করলে কোনো NAT নিয়মই সাহায্য করবে না, আর বাড়ির রাউটারের VPN পৃষ্ঠার সবুজ বাতি কিছুই বোঝায় না।

নিশ্চিত করুন বাড়ির লাইন সত্যিই CGNAT-এর পিছনে

রাউটার তার WAN ইন্টারফেসে যে ঠিকানা জানায় তার সঙ্গে বাইরের কোনো সেবা যা দেখে তার তুলনা করুন। 100.64.0.0/10-এর মধ্যে যা কিছু আছে, অর্থাৎ 100.64.x.x থেকে 100.127.x.x পর্যন্ত, তা RFC 6598-এর ভাগ করা ঠিকানা পরিসর এবং ইন্টারনেট থেকে পৌঁছানো যায় না। রাউটার সাধারণ ব্যক্তিগত ঠিকানা দাবি করলে এবং সার্বজনীন অনুসন্ধান অসম্পর্কিত কিছু ফেরত দিলেও আপনি একই সিদ্ধান্তে পৌঁছান। CGNAT লাইনে এমন সার্বজনীন ঠিকানাও থাকতে পারে যা কেবল পরের lease পর্যন্ত টেকে, তাই পোর্ট ফরওয়ার্ডিং এক ঘণ্টা কাজ করছে মনে হয় এবং তারপর চুপচাপ মরে যায়।

কিছু প্রদানকারী সত্যিই আসল সার্বজনীন ঠিকানা দেন, কিন্তু আবাসিক অ্যাকাউন্টে আসা 80 ও 443 পোর্ট ব্লক করেন। আপনার সেবা কেবল ওয়েব হলে এবং WAN ঠিকানা সত্যিই সার্বজনীন হলে relay বানানোর আগে সহায়তা দলকে জিজ্ঞাসা করুন। না হলে নিচের নকশা প্রতিটি পোর্টে সমানভাবে প্রযোজ্য, এবং পরীক্ষাটি রাউটারের দিকে থামানোই ভালো: প্রদানকারীর নেটওয়ার্কে থাকা অনুবাদক সংযোগটি আপনার WAN ইন্টারফেসে পৌঁছানোর আগেই শেষ করে দেয়।

নামটি VPS-এর ঠিকানার দিকে নির্দেশ করুন

DNS ট্রাফিক এগিয়ে পাঠায় না, তাই সেবার A রেকর্ডে VPS-এর সার্বজনীন ঠিকানা থাকতে হবে। 192.168.1.20-এর দিকে A রেকর্ড কেবল সেই ক্লায়েন্টদের জন্য কাজে লাগে যারা ইতিমধ্যে VPN-এর ভেতরে; ইন্টারনেট থেকে এটি এমন ঠিকানায় রিজলভ হয় যা কেউ রাউট করতে পারে না। নিজে VPS-এর প্রশাসনিক প্রবেশের জন্য আমি আলাদা নাম রাখি, যাতে রেকর্ড কোন হোস্টের সঙ্গে সম্পর্কিত তা কখনো না গুলিয়ে ফেলি।

VPS ও বাড়ির মেশিন দুটোই যদি HTTP পরিবেশন করে, তবে প্রত্যেককে নিজের নাম দিন এবং কে উত্তর দেবে তা VPS-কে ঠিক করতে দিন। দুটোকেই এক নামে মিলিয়ে প্রক্সি সঠিক backend বেছে নেবে এমন আশা করা ঠিক সেই পদ্ধতি যাতে আপনি গোটা দুপুর ভুল হোস্টে ত্রুটি খোঁজেন।

একটি পোর্ট DNAT-এ, SSH 22-এ থাকুক

সরাসরি বিকল্প হলো VPS-এ গন্তব্য NAT। চলমান কার্নেলের জন্য forwarding চালু করুন এবং নিয়মে বাড়ির সার্ভারের টানেল ঠিকানা রাখুন, তার LAN ঠিকানা নয়:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -p tcp -d 198.51.100.10 --dport 5022 -j DNAT --to-destination 10.8.0.2

নিজে VPS-এর প্রতি SSH 22-এ রাখুন এবং অন্য একটি পোর্ট, যেমন 5022, বাড়ির মেশিনের দিকে পাঠান। 22 কোনো বন্ধ মেশিনে পাঠালে সেই একমাত্র পথ হারাবেন যা এটি ঠিক করতে পারত। একই যুক্তি প্রক্সির ক্ষেত্রেও প্রযোজ্য: VPS-এর ব্যবস্থাপনা পোর্ট relay নিয়মের বাইরে রাখুন।

নিয়মগুলো কাজ শুরু করলে সেগুলো স্থায়ী করুন। Debian বা Ubuntu-তে apt install iptables-persistent এবং তারপর netfilter-persistent save সেগুলো /etc/iptables/rules.v4-এ লেখে। firewalld থাকা হোস্টে সমতুল্য হলো জোনে স্থায়ী পোর্ট ফরওয়ার্ডিং, যা কার্যকর হওয়ার আগে firewall-cmd --reload দরকার। কেবল মেমোরিতে বাস করা নিয়ম প্রদানকারীর প্রথম রক্ষণাবেক্ষণ রিবুটে হারিয়ে যায়, সাধারণত খারাপ সময়ে।

ফেরার পথ ঠিক করুন বা তার প্রয়োজন এড়ান

DNAT কেবল গন্তব্য পুনর্লিখন করে। বাড়ির সার্ভার সংযোগটি মূল ক্লায়েন্ট ঠিকানা থেকে দেখে, আর যদি তার ডিফল্ট রুট বাড়ির রাউটারের দিকে থাকে তবে উত্তরটি বাড়ির WAN দিয়ে বেরিয়ে যায় যেখানে প্রদানকারীর অনুবাদক তা ফেলে দেয়। এই অসমতাই ছিল দ্বিতীয় ত্রুটি যা আমি পেয়েছি, DNAT নিয়ম পুরোপুরি সঠিক দেখানোর পরে।

দুটি সংশোধন কাজ করে। বাড়ির মেশিনকে নীতি-রুট দিন যাতে টানেল থেকে আসা ট্রাফিক টানেল দিয়েই ফেরে:

ip rule add from 10.8.0.2 table 100
ip route add default dev wg0 table 100

অথবা VPS-কে উৎস পুনর্লিখন করতে দিন যাতে উত্তরের এমন ঠিকানা থাকে যা সে পৌঁছাতে পারে, এবং conntrack তা বাইরে যাওয়ার সময় উল্টে দিক:

iptables -t nat -A POSTROUTING -d 10.8.0.2 -p tcp --dport 5022 -j SNAT --to-source 10.8.0.1

SNAT সংস্করণটি আসল ক্লায়েন্ট ঠিকানা বাড়ির সার্ভার থেকে লুকায়, তাই অ্যাপ্লিকেশন লগ peer হিসেবে 10.8.0.1 দেখায়। মূল ঠিকানা অ্যাপ্লিকেশন স্তরে পাঠান, বা প্রতি ক্লায়েন্ট লগিং হারানো মেনে নিন, কিন্তু এই সিদ্ধান্ত সচেতনভাবে নিন, কোনো ঘটনার সময় তা আবিষ্কার করার বদলে।

পুরো পথ বাইরে থেকে যাচাই করুন

এমন নেটওয়ার্ক থেকে যাচাই করুন যা VPS নয় আর বাড়িও নয়: মোবাইল ডেটায় ফোন, বা অন্য কোথাও সস্তা shell। nc -vz files.example.net 5022-এর সফল সংযোগ জানানো উচিত, আর openssl s_client -connect files.example.net:443 -servername files.example.net-এর সার্বজনীন নামের সার্টিফিকেট দেখানো উচিত। তারপর প্রদানকারীর নিরাপত্তা গোষ্ঠী বা ক্লাউড ফায়ারওয়াল দেখুন। যে DNAT নিয়ম কখনো প্যাকেট দেখে না তা সাধারণত হোস্টের এক স্তর উপরে ব্লক হয়।

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