টানেলের মাধ্যমে দূরের /24 নেটওয়ার্কে পৌঁছানো: NETMAP, DNAT নাকি রুট?
NETMAP দিয়ে পুরো প্রিফিক্স ম্যাপ করুন, প্রতি হোস্টের জন্য DNAT নিয়ম যোগ করুন বা আসল রেঞ্জ রাউট করুন, এবং সিদ্ধান্ত নিন দূরের পক্ষকে কী দেখতে হবে ও কে ট্র্যাফিক শুরু করতে পারবে তার ভিত্তিতে।
টানেল এন্ডপয়েন্টের পেছনের একটি সাবনেটে তিনভাবে পৌঁছানো যায়, এবং এক মিনিটের তথ্য সংগ্রহ সাধারণত দুটিকে বাদ দেয়। তথ্যগুলো হলো—সেখানের সার্ভারগুলোকে কি ব্যবহারকারীদের আলাদা করতে হবে, সেখান থেকে কেউ কি কখনো আপনার রেঞ্জের দিকে ডায়াল করবে, এবং দূর প্রান্তের রাউটার কে সম্পাদনা করতে পারবে। এই তিনটির উত্তর দিলে নকশা নিজেই বেছে নেওয়া হয়। বাকিটা ধরে নেয় যে আপনি এন্ডপয়েন্ট চালান এবং এর ফায়ারওয়াল সম্পাদনা করতে পারেন।
তিনটি বিকল্প, এবং প্রতিটি আসলে কী বদলায়
প্রিফিক্স ম্যাপিং, প্রতি-হোস্ট DNAT এবং রাউটেড প্রিফিক্স—সবই একই দুটি রেঞ্জের মধ্যে প্যাকেট সরায়, কিন্তু ভিন্ন ভিন্ন জিনিস বদলায়। ম্যাপিং একটি ভুয়া অ্যালিয়াস রেঞ্জ বানায় এবং চলার পথে ঠিকানাগুলো গাণিতিকভাবে পুনর্লিখন করে। প্রতি-হোস্ট নিয়মও পুনর্লিখন করে, শুধু প্রতিটি গন্তব্য হাতে নামকরণ করা হয়। রাউটেড প্রিফিক্স কিছুই পুনর্লিখন করে না: প্যাকেটগুলো আসল ঠিকানা ধরে রাখে এবং দুই প্রান্ত একমত হয় সেই ঠিকানাগুলো কোথায় থাকে।
| What the far side needs | Prefix mapping | Per-host DNAT | Routed prefix |
|---|---|---|---|
| Users visible to its logs | Only without source NAT | Same condition | Yes, unchanged |
| To start a connection toward you | No, alias is local | No, same reason | Yes, both ends route |
| To absorb a new host | Yes, arithmetic only | No, one rule per address | Yes, it simply routes |
| To require no config change | Yes, with source NAT | Yes, same condition | No, it needs a route back |
বাদ দেওয়া শুরু করুন দূরের প্রান্ত থেকে, যেখানে সীমাবদ্ধতা বদলানো সবচেয়ে কঠিন। যদি সেখানের সার্ভার ক্লায়েন্ট ঠিকানা লগে লেখে, সেগুলো অনুমোদিত তালিকার সঙ্গে মেলায় বা অন্য সিস্টেমে দেয়, তবে সোর্স অনুবাদ করলে তার একমাত্র শনাক্তকারী ধ্বংস হয়। যদি দূরের প্রান্তকেও ডায়াল করতে হয়, অনুবাদ পুরোপুরি বাতিল, কারণ সেখানে কেউ জানে না অ্যালিয়াসটি আছে। কেবল যখন দূরের প্রান্ত শুধু অনুরোধের উত্তর দেয়, তখন সস্তা বিকল্পগুলো নিরাপদ হয়।
প্রিফিক্স জোড়া, এবং আকার কেন মিলতে হবে
NETMAP হলো nat টেবিলের একটি টার্গেট যা একই দৈর্ঘ্যের দুই প্রিফিক্সের জোড়ায় কাজ করে। এর ভেতরে প্রতি-ঠিকানার টেবিল নেই: এটি প্রিফিক্স সরিয়ে হোস্ট বিট রাখে এবং নতুন প্রিফিক্সে আবার জুড়ে দেয়, তাই /24 ম্যাপ হয় /24-এ এবং কখনো /25-এ নয়। অবস্থান দিক নির্ধারণ করে: PREROUTING-এ গন্তব্য মিল প্যাকেট কোথায় যাচ্ছে তা পুনর্লিখন করে, আর POSTROUTING-এ সোর্স মিল তা কোথা থেকে এসেছে তা পুনর্লিখন করে।
192.168.2.17-এর একটি হোস্ট আপনার ক্লায়েন্টদের কাছে 10.50.1.17 হিসেবে দেখা যায়, এবং শেষ অক্টেটটি সাজসজ্জা নয় — এটি দুই পাশে একই সংখ্যা। কাল 192.168.2.40-এ একটি হোস্ট যোগ করুন, এর অ্যালিয়াস হবে 10.50.1.40, সম্পাদনার কোনো নিয়ম ছাড়াই।
ক্লায়েন্টদের এখনো অ্যালিয়াস রেঞ্জের জন্য আপনার বক্সের দিকে নির্দেশ করা রুট দরকার, যদি না অ্যালিয়াসটি এমন সাবনেটের ভেতরে পড়ে যা তারা ইতিমধ্যে পৌঁছায়। গেটওয়ের অ্যালিয়াসের জন্য রুট দরকার নেই, কারণ গন্তব্য অনুবাদ রুট অনুসন্ধানের আগে PREROUTING-এ চলে। ফরওয়ার্ডিংও চালু থাকতে হবে, নইলে কার্নেল পুনর্লিখনের পর প্যাকেট ফেলে দেয়। নিচের তিনটি কমান্ডই Debian-ধাঁচের গেটওয়েতে সম্পূর্ণ সেটআপ, যেখানে ক্লায়েন্ট br0-এ, অ্যালিয়াস 10.50.1.0/24-এ এবং টানেল tun0-এ।
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i br0 -d 10.50.1.0/24 -j NETMAP --to 192.168.2.0/24
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADEউত্তরটিকে নিজের ফেরার পথ খুঁজতে হবে
গন্তব্য পুনর্লিখন কেবল ঠিক করে প্যাকেট কোথায় পৌঁছে দেওয়া হবে। দূর প্রান্তের সার্ভারকে এখনো এমন ঠিকানার উত্তর দিতে হবে যা সে পৌঁছাতে পারে, আর এটি সাজানোর দুটি উপায় আছে। সোর্স অনুবাদ করুন যাতে উত্তর আপনার বক্সে ফেরে, অথবা সোর্স অক্ষত রাখুন এবং দূরের প্রান্তকে ক্লায়েন্ট রেঞ্জের রুট দিন।
বাইরের পথে ম্যাস্কারেডিং ছোট পথ: POSTROUTING-এ একটি নিয়ম এবং দূরের প্রান্ত আপনার টানেল ঠিকানা দেখে, তাই তার নিজের রুট দরকার নেই। খরচ হলো প্রতিটি ব্যবহারকারী একটি ঠিকানায় মিলে যায়, এবং প্রতি-ব্যবহারকারী লগ অর্থহীন হয়ে পড়ে। সোর্স অক্ষত রাখা সেই তথ্য ধরে রাখে, কিন্তু তখন দূরের সাইটকে ক্লায়েন্ট রেঞ্জের উত্তর টানেল দিয়ে ফেরত পাঠাতে হয়। একটি OpenVPN সার্ভারে এটি হলো পাঠানো push "route 10.50.9.0 255.255.255.0", সাথে একটি route 192.168.2.0 255.255.255.0 লাইন।
ব্যয়বহুল ব্যর্থতা হলো প্রতিটির অর্ধেক করা। যদি কিছু ট্র্যাফিক ম্যাস্কারেড করেন অথচ দূরের প্রান্ত অন্য ট্র্যাফিকের জন্য ফেরার রুটও বহন করে, উত্তর আসে এমন ইন্টারফেসে যেখানে সংযোগ-ট্র্যাকিং এন্ট্রি কখনো দেখা যায়নি। সার্ভার যে অনুরোধ পরিবেশন হিসেবে লগ করেছে তার জন্য ক্লায়েন্ট টাইমআউট জানায়। প্রবাহের দুই দিকই একই netfilter ইনস্ট্যান্স অতিক্রম করতে হবে: একটি গেটওয়ে অনুবাদ করছে, দুইটি ফায়ারওয়াল ধারাবাহিকভাবে নয়।
conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -nএন্ট্রিটি দুই দিকেই পড়ুন: মূল টাপলে গন্তব্যে আপনার অ্যালিয়াস থাকে, আর উত্তরের টাপলে আসল ঠিকানা থাকে। উত্তরের টাপল অনুপস্থিত থাকলে সমস্যা নিয়মে নয়, ফেরার পথে। PREROUTING কাউন্টার যদি কখনো নড়ে না থাকে, প্যাকেট কখনো সেই হুকে পৌঁছায়নি।
সংঘর্ষ এবং যে অনুসন্ধান আগে চলে
দুটি ভিন্ন রেঞ্জ সংঘর্ষ করতে পারে, এবং দুই ব্যর্থতাই খারাপ নিয়মের বদলে ভাঙা টানেলের মতো দেখায়। যে অ্যালিয়াস বানান তা পুরো পথে অব্যবহৃত হতে হবে, এবং আসল দূর-প্রান্তের রেঞ্জ আপনার নেটওয়ার্কে আগেই থাকা চলবে না। নকল পরস্পরবিরোধী ভুল-হোস্ট ট্র্যাফিক তৈরি করে, যা প্রত্যাখ্যাত সংযোগের চেয়ে নির্ণয় করা কঠিন। নিয়ম যোগ করার আগে রাউটিং টেবিলকে জিজ্ঞাসা করুন।
গেটওয়েতে ip route get 192.168.2.17 টানেল ডিভাইসের নাম বলা উচিত; স্থানীয় ব্রিজ মানে দূরের রেঞ্জ ছায়াচ্ছন্ন এবং কোনো nat নিয়ম তা ঠিক করবে না। আপনার নিজের নেটওয়ার্ক যদি আগেই 192.168.2.0/24 ব্যবহার করে, সংঘর্ষের ওপর ম্যাপিং চাপানোর বদলে দূরের সাইটকে পুনঃনম্বর দিন।
আসল ক্লায়েন্ট থেকে পরীক্ষা, তারপর সংরক্ষণ
এমন মেশিন থেকে পরীক্ষা করুন যা সত্যিই অ্যালিয়াস ব্যবহার করবে, গেটওয়ে থেকে নয়, কারণ স্থানীয়ভাবে উৎপন্ন ট্র্যাফিক কখনো একইভাবে PREROUTING অতিক্রম করে না। অ্যালিয়াসযুক্ত একটি হোস্টে সংযোগ খুলুন এবং কাউন্টার ও conntrack এন্ট্রি একসাথে দেখা যাচ্ছে কিনা দেখুন, তারপর বন্ধ করে এন্ট্রি চলে যাওয়া নিশ্চিত করুন। পুরোনো এন্ট্রি অর্ধ-খোলা সংযোগের দিকে ইঙ্গিত করে, যার সাধারণ অর্থ উত্তর কখনো ফেরেনি।
curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17দুই বা তিনটি সফল সংযোগ গাণিতিক হিসাব প্রমাণ করে, কিন্তু স্থায়িত্ব বা পরবর্তী প্রকৌশলী সম্পর্কে কিছু বলে না। নিয়মগুলো সেখানে সংরক্ষণ করুন যেখানে বুট প্রক্রিয়া সেগুলো পড়ে, যা Debian ও Ubuntu-তে মানে iptables-save > /etc/iptables/rules.v4 এবং netfilter-persistent সক্রিয়। রিবুটে হারিয়ে যাওয়া ম্যাপিং না থাকার চেয়ে খারাপ, কারণ বিভ্রাট আসে সাম্প্রতিক কোনো পরিবর্তন ছাড়াই, দোষ দেওয়ার মতো।
নিয়মের পাশে একটি টীকা রাখুন: অ্যালিয়াস রেঞ্জ, আসল রেঞ্জ, জোড়ার কারণ এবং কোন পক্ষ শুরু করতে পারে। সেই টীকা একটি নকশাকে কেউ মুছতে সাহস করে না এমন নিয়মের স্তূপ থেকে আলাদা করে। এটি পরের প্রশ্নটিও নিষ্পত্তি করে, যখন দূরের সাইট একটি হোস্ট যোগ করে এবং কেউ কনফিগার করেনি এমন ঠিকানা আগেই উত্তর দেয়। টীকায় যদি লেখা থাকে দূরের প্রান্তের ফেরার রুট দরকার, পরবর্তী ব্যক্তি জানবে ম্যাস্কারেড নিয়ম সরালে সংযোগ বিচ্ছিন্ন হবে। এখানে নথিভুক্তি সস্তা; রাত তিনটায় NAT-নির্ভরতা নতুন করে আবিষ্কার করা নয়।