SNAT, DNAT ও Masquerade: প্রতিটি VPN NAT নিয়ম কী কাজ করে

VPN গেটওয়ের দুই পাশে ক্যাপচার বসান, আর একটি ফ্লো চারটি আলাদা ঠিকানা দেখাতে পারে। সোর্স NAT আবার লিখে দেয় প্যাকেটটি কোথা থেকে আসছে বলে দাবি করছে; ডেস্টিনেশন NAT আবার লিখে দেয় এটি কোথায় যাচ্ছে। Masquerade কোনো তৃতীয় দিক নয়, এটি একটি সোর্স-NAT নিয়ম যা নির্দিষ্ট মানের বদলে আউটগোয়িং ইন্টারফেসের ঠিকানা নেয়। তিনটির মধ্যে কোনটি আপনার সত্যিই দরকার তা নাম দিন, আর বেশিরভাগ «VPN ভাঙা» টিকিট রিটার্ন পাথ নিয়ে প্রশ্নে পরিণত হবে।

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

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

ডেস্টিনেশন NAT, DNAT, বরং গন্তব্য বদলায়। UDP 51820-এ একটি পাবলিক ঠিকানায় পাঠানো প্যাকেট 10.8.0.2:51820-এ থাকা অভ্যন্তরীণ WireGuard সার্ভারে আবার লেখা যেতে পারে। এভাবেই হোম রাউটার বা ক্লাউড লোড ব্যালান্সার একটি VPN লিসনার প্রকাশ করে, আর এটি টানেল পরে কী বহন করতে পারে সে সম্পর্কে কিছুই বলে না।

Masquerade SNAT পরিবারের অন্তর্গত। নিয়মটি কোনো ঠিকানা নাম দেয় না; প্যাকেট বেরোনোর সময় আউটগোয়িং ইন্টারফেসে যে ঠিকানা থাকে তা-ই ব্যবহার করে। Linux এটিকে নিজস্ব টার্গেট দেয়, আর DHCP বা PPPoE থেকে ঠিকানা পাওয়া WAN ইন্টারফেসে এটি স্বাভাবিক পছন্দ।

ম্যাপিং কোথায় থাকে তা ব্যর্থতা ঠিক করে

প্রতিটি সীমানায় টাপল লিখে রাখুন: টানেলের আগে, তার ভেতরে এবং পাবলিক ইন্টারফেসে। টানেলের ভেতরের ক্যাপচার বৈধভাবেই বাইরেরটির থেকে আলাদা, আর অনুবাদ কোথায় ঘটছে না জেনে দুটির তুলনা করলে ভুল হোস্টের পেছনে ছুটতে হবে।

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

আরেকটি সাধারণ ভুল হলো টানেল রাউটেবিলিটি তৈরি করবে বলে আশা করা। যে প্রাইভেট ক্লায়েন্টের প্যাকেট ইন্টারনেটে যায় তার একটি বৈধ ইগ্রেস ব্যবস্থা দরকার: ডিফল্ট রুট, ফরওয়ার্ডিং গেটওয়ে এবং সাধারণত পাবলিক ঠিকানায় সোর্স অনুবাদ। শুধু এনক্রিপশন প্রাইভেট ঠিকানা পৌঁছানোর যোগ্য করে না।

Masquerade না স্পষ্ট SNAT

দুটিকে তাদের প্রতিশ্রুতি দিয়ে তুলনা করুন। Masquerade ইগ্রেস ঠিকানা বেছে নেয়, স্পষ্ট SNAT সেটি পিন করে। স্থির পাবলিক ঠিকানার গেটওয়েতে পিনিং লগ ও অংশীদার অনুমোদন-তালিকাকে একটি অনুমানযোগ্য মান দেয়। গতিশীল WAN লিংকে পিন করা SNAT ঠিকানা লিজ বদলানোর সঙ্গে সঙ্গে ভুল হয়ে যায়, আর Masquerade ঠিক এই ক্ষেত্রের জন্যই তৈরি।

নির্বাচনের মতোই পরিধিও গুরুত্বপূর্ণ। গেটওয়ে ছাড়া প্রতিটি প্যাকেটের সঙ্গে মেলা Masquerade নিয়ম, উৎস বা গন্তব্যের সীমা ছাড়া, আপনি অক্ষত রাখতে চাওয়া ট্রাফিকও অনুবাদ করে, অন্য প্রাইভেট নেটওয়ার্কের ট্রাফিকসহ। নিয়মটি ক্লায়েন্ট রেঞ্জ, অভীষ্ট গন্তব্য ও ইন্টারফেসে সীমাবদ্ধ করুন।

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

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

Linux গেটওয়েতে নিয়ম পড়া

10.8.0.0/24-এ ক্লায়েন্ট ও eth0 নামের WAN ইন্টারফেস আছে এমন রিমোট-অ্যাক্সেস গেটওয়েতে ফরওয়ার্ডিং চালু এবং ফ্লো অনুমোদনকারী ফিল্টার পলিসি দরকার, তবেই কোনো NAT নিয়ম সাহায্য করতে পারে। iptables সংস্করণ দুই দিকই nat টেবিলে রাখে:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 51820 \
  -j DNAT --to-destination 10.8.0.2:51820

nftables রূপটি একই দুটি হুক নামযুক্ত ইন্টারফেস ও স্পষ্ট চেইন দিয়ে ব্যবহার করে:

nft add rule ip nat postrouting ip saddr 10.8.0.0/24 oifname "eth0" masquerade
nft add rule ip nat prerouting iifname "eth0" udp dport 51820 dnat to 10.8.0.2:51820

দুটি স্নিপেটই ধরে নেয় ফিল্টার চেইন ইতিমধ্যে ফরওয়ার্ড করা ফ্লো গ্রহণ করে। NAT কোনো অনুমোদন নিয়ম নয়, আর সঠিকভাবে অনূদিত প্যাকেটও একটি টেবিল পরে বাদ পড়তে পারে। conntrack -L দিয়ে জীবন্ত ম্যাপিং নিশ্চিত করুন, nft list ruleset বা iptables-save -t nat দিয়ে কী লোড হয়েছে তা নিশ্চিত করুন, তারপর ঠিকানা সত্যিই বদলাচ্ছে দেখতে দুই ইন্টারফেসে ক্যাপচার করুন।

খারাপ নিয়মের মতো দেখানো ব্যর্থতার ধরন

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

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

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

নিয়ম সংরক্ষণের আগে চেকলিস্ট

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

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