CGNAT-এর পিছন থেকে VPN ক্লায়েন্ট পোর্ট প্রকাশ করুন: চেকলিস্ট

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

সার্ভারটি আদৌ ফরওয়ার্ড করবে কি না নিশ্চিত করুন

একটি অনুবাদ লেখার আগেই এই ঘরটি টিক দিন। কার্নেল যে প্যাকেট ফরওয়ার্ড করতে অস্বীকার করে তার জন্য DNAT নিয়ম নিয়ম পার্সার গ্রহণ করে, তারপর ফরওয়ার্ড পথ এটি ফেলে দেয়, যা একটি টাইমআউট তৈরি করে যা ফায়ারওয়াল সমস্যার মতো দেখায়।

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1

চলমান কার্নেলে এটি সেট করা রিবুট জুড়ে সেট করার সমান নয়। net.ipv4.ip_forward=1 কে /etc/sysctl.d/-এর অধীনে একটি ফাইলে লিখুন, sysctl --system চালান, তারপর ফাইলটি ধরা পড়েছে বলে বিশ্বাস করার বদলে মানটি আবার পড়ুন। যে কনটেইনার নিজের নেটওয়ার্ক নেমস্পেস পরিচালনা করে তার সেই নেমস্পেসের ভিতরে একই মান দরকার, শুধু হোস্টে নয়।

যদি পড়া এখনও শূন্য হয়, এখানেই থামুন। নিচের কোনো কিছুই কাজ করবে না।

কোনো নিয়ম এটিকে উল্লেখ করার আগেই টানেল ঠিকানাটি পিন করুন

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

client-config-dir /etc/openvpn/ccd
ifconfig-push 10.77.0.14 10.77.0.13

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

পুনঃসংযোগের পরে ঠিকানা বদলে গেলে থামুন। চলমান লক্ষ্য অনুসরণ করা NAT নিয়ম মাঝে মাঝে ব্যর্থ হবে এবং আপনাকে কিছুই শেখাবে না।

উভয় দিকেই অনুবাদ করুন

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

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 29443 -j DNAT --to-destination 10.77.0.14:29443
iptables -t nat -A POSTROUTING -d 10.77.0.14 -p tcp --dport 29443 -j SNAT --to-source 10.77.0.13

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

iptables -t nat -S দিয়ে দুটি নিয়মই আবার পড়ুন এবং নিশ্চিত করুন ইন্টারফেসের নামটি সেই একটি যা পাবলিক ঠিকানা বহন করে। যে হোস্ট ইতিমধ্যে nftables দিয়ে ফিল্টার করে সেখানে টুল মেশানোর বদলে মিলে যাওয়া ঠিকানা পরিবারের nftables NAT চেইনে অনুবাদটি লিখুন।

ফিল্টার টেবিলটিকে যেতে দিন

NAT টেবিলগুলি হেডার পুনর্লিখন করে; তারা অনুমতি দেয় না। ডিফল্ট DROP নীতিতে ফরওয়ার্ড হওয়া প্রবাহের নিজস্ব গ্রহণ দরকার, সাথে ফেরত দিকটি যা বেশিরভাগ নীতি ইতিমধ্যে established,related নিয়মে ঢেকে রাখে।

iptables -A FORWARD -i eth0 -o tun0 -p tcp --dport 29443 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

কিছু যোগ করার আগে FORWARD চেইনের নীতি পরীক্ষা করুন, কারণ একটি আগেভাগের DROP-এর ক্রমই ঠিক করে আপনার নিয়ম আদৌ দেখা হবে কি না। যে হোস্টের ফিল্টারিং nftables-এ থাকে সেখানে inet টেবিলের forward হুকে সমতুল্য নিয়মটি যোগ করুন এবং নিশ্চিত করুন বেস চেইনটি কেবল লোকাল ইনপুট নয়, সত্যিই ফরওয়ার্ড হওয়া ট্র্যাফিক দেখে। যদি নতুন নিয়মের প্যাকেট কাউন্টার শূন্যে থাকে অথচ NAT কাউন্টার বাড়ে, তবে প্যাকেটটি আপনার নিয়মের আগেই ফেলা হচ্ছে। এটি চেইনের ক্রম পড়ার সংকেত, একই নিয়মের দ্বিতীয় কপি যোগ করার নয়।

বাইরের কোনো নেটওয়ার্ক থেকে এটি প্রমাণ করুন

অসম্পর্কিত একটি নেটওয়ার্ক থেকে পরীক্ষা করুন। একই LAN-এর অন্য মেশিন থেকে একটি প্রোব hairpin NAT সমর্থনের মধ্য দিয়ে যেতে পারে এবং দূরবর্তী ক্লায়েন্ট যে পথ ব্যবহার করে তা কখনোই চালায় না, তাই সেখানে সবুজ ফলাফল ভুল জিনিস প্রমাণ করে।

tcpdump -ni any port 29443
conntrack -L | grep 29443

সার্ভারে এবং ক্লায়েন্টে একই সময়ে ক্যাপচার চালান। সার্ভারের ক্যাপচার দেখায় অনূদিত প্যাকেটটি টানেলের দিকে বেরোচ্ছে কি না; ক্লায়েন্টের ক্যাপচার দেখায় অনুরোধটি পৌঁছাচ্ছে কি না এবং উত্তরটি কোথায় ঠিকানাকৃত। conntrack -L-এ একটি অনুবাদ এন্ট্রি প্রমাণ করে নিয়মটি মিলেছিল, আর এর অনুপস্থিতি প্রমাণ করে প্যাকেটটি কখনো NAT চেইনে পৌঁছায়নি।

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