কেন CGNAT-এর পিছনে থাকা VPN সার্ভার কখনও সংযোগ গ্রহণ করে না

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

শেয়ার করা ঠিকানাটি নিশ্চিত করতে দুই মিনিট লাগে এবং এক সপ্তাহের কনফিগারেশন পরিবর্তন ঠেকায়।

যে লক্ষণগুলো ক্যারিয়ার NAT-এর দিকে ইঙ্গিত করে

রাউটারের স্ট্যাটাস পেজের WAN ঠিকানাটি বাইরের লুকআপ যে ঠিকানা রিপোর্ট করে তার সঙ্গে তুলনা করুন। 100.64.0.0/10-এর ভিতরের WAN ঠিকানা সাধারণ লক্ষণ, এবং প্রাইভেট রেঞ্জ 10/8, 172.16/12 ও 192.168/16 একই অর্থ বোঝায়। যদি traceroute একই পাবলিক হপ বারবার দেখায়, বা কোনো প্রাথমিক হপ প্রাইভেট ঠিকানা দিয়ে উত্তর দেয়, তাহলে রাউটার ও ইন্টারনেটের মধ্যে আরেকটি ট্রান্সলেটর বসে আছে। কিছু ISP নির্ধারিত ঠিকানা শুধু কাস্টমার পোর্টালে দেখায়, তাই traceroute-এর সঙ্গে সেই মানটি রপ্তানি করুন।

প্রোটোকল বা পোর্ট পরিবর্তন করলে কাজ হয় না, কারণ সমস্যাটি বন্ধ পোর্ট নয়, বরং ইনবাউন্ড পৌঁছানোর ক্ষমতা।

কেন ফরওয়ার্ডিং ও ডায়নামিক DNS এটি ঠিক করতে পারে না

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

ক্লায়েন্ট পুনঃকনফিগার করলেও কাজ হবে না, কারণ ব্যর্থতাটি কোনো ক্লায়েন্ট সেটিং পড়ার আগেই ঘটে।

স্পষ্ট রুটসহ VPS-এর মাধ্যমে রিলে

সামনে একটি পাবলিক ঠিকানা বসান ট্রাফিক বহন করতে পারে এমন সবচেয়ে ছোট VPS ভাড়া নিয়ে, তারপর হোম রাউটারকে সেদিকে আউটবাউন্ড ডায়াল করতে দিন। হোম নেটওয়ার্ক থেকে আউটবাউন্ড UDP ক্যারিয়ার NAT অতিক্রম করে, তাই টানেলটি ভিতর থেকে প্রতিষ্ঠিত হয় এবং VPS-ই পৌঁছানোর উপযোগী এন্ডপয়েন্ট হয়ে ওঠে। হোমের দিকটি স্থির টানেল ঠিকানাসহ একটি ক্লায়েন্ট হয়, সার্ভার নয়।

VPS-এ ক্লায়েন্ট-নির্দিষ্ট একটি ডিরেক্টরি এন্ট্রি যোগ করুন যাতে সার্ভার জানে হোম সাবনেট কোন পিয়ারের, এবং একটি মিলে যাওয়া কার্নেল রুট যোগ করুন।

# /etc/openvpn/server/ccd/home-site.conf
ifconfig-push 10.8.0.10 255.255.255.0
iroute 192.168.50.0 255.255.255.0

# server.conf
client-config-dir /etc/openvpn/server/ccd
route 192.168.50.0 255.255.255.0
push "route 10.8.0.0 255.255.255.0"

iroute লাইনটি OpenVPN-কে বলে কোন ক্লায়েন্ট হোম সাবনেটের ট্রাফিক পায়; route লাইনটি সেই সাবনেট VPS-এর কার্নেল টেবিলে বসায় যাতে প্যাকেট আদৌ টানেলে ঢোকে। প্রকাশিত সার্ভিসের জন্য একটি ডেস্টিনেশন NAT নিয়ম যোগ করুন যা পাবলিক পোর্ট 10.8.0.10-এ ফরওয়ার্ড করে, এবং net.ipv4.ip_forward চালু করুন।

বাইরে থেকে পথটি পরীক্ষা করুন

পাবলিক দিকের প্রতিটি হপ যাচাই করুন, কারণ সফল টানেল প্রমাণ করে না যে সার্ভিসে পৌঁছানো যায়। VPS-এ লিসেন-স্টেট ও প্যাকেট ক্যাপচার 'কিছুই আসেনি' এবং 'এসেছে ও ফেলে দেওয়া হয়েছে'-এর পার্থক্য করে।

ss -lunp | grep 1194
tcpdump -ni any udp port 1194
nft list ruleset | grep -A4 dnat

# from a phone on mobile data, not the home Wi-Fi
nc -vz -u 203.0.113.10 1194

ক্যাপচারে ফোন থেকে প্যাকেট দেখা গেলে কিন্তু উত্তর না এলে, পরবর্তী গন্তব্য সার্ভার কনফিগারেশন বা ফায়ারওয়াল। ক্যাপচারে কিছু না দেখা গেলে, ক্লায়েন্ট তখনও রিজলভ করছে বা ভুল ঠিকানায় পাঠাচ্ছে।

আগে মূল্য যাচাই করা উচিত এমন বিকল্প

ISP থেকে ডেডিকেটেড IPv4 ঠিকানা সবচেয়ে ছোট সমাধান এবং সাধারণত সামান্য মাসিক ফি। নেটিভ IPv6 উভয় প্রান্তে ট্রান্সলেশন সরিয়ে দেয় যখন VPN, ক্লায়েন্ট নেটওয়ার্ক ও DNS রেকর্ড সবই এটি বহন করে। হোম নেটওয়ার্কের ভিতরে সাবনেট রাউটারসহ একটি মেশ ওভারলে VPS ছাড়াই একই রিলে দেয়, তবে একটি সমন্বয় সেবার উপর নির্ভরতার বিনিময়ে।

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