VPN সাবনেটে পোর্ট ফরওয়ার্ডে SNAT করা উচিত কি?

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

উত্তর কেন ভিন্ন পথ নেয়

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

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

বিশ্বাস করার মতো যথেষ্ট সংকীর্ণ সোর্স নিয়ম

রাউটারকেই সেই সোর্স বানান যেটিতে দূরবর্তী হোস্ট উত্তর দেয়। এই বিন্যাসে WAN ঠিকানা হলো 203.0.113.24, LAN হলো 192.168.88.0/24, রাউটারের টানেল ঠিকানা 172.20.5.1, এবং সার্ভিস উত্তর দেয় 172.20.5.40:8443। নিচের নিয়মটি গন্তব্য অনুবাদের পরে প্যাকেটের সাথে মেলে, তাই এটি পাবলিক ঠিকানার বদলে অনূদিত ঠিকানার নাম নেয়। এতে কিছুই ক্লায়েন্টের ঠিকানার উপর নির্ভর করে না, এবং ঠিক সেটাই মূল কথা।

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

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

কখন সর্বব্যাপী মাস্করেড সৎ পছন্দ

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

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

প্রকাশের আগে কাউন্টার দেখুন

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

iptables -t nat -L POSTROUTING -v -n --line-numbers

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