কীভাবে NAT-এর পেছনের একটি OpenVPN ক্লায়েন্ট ইন্টারনেট এগজিট হয়

তিনটি Linux হোস্ট, এক নকশা: প্রকাশ্য OpenVPN হাব, একটি ল্যাপটপ এবং সাধারণ হোম রাউটারের পেছনে একটি এগজিট, যা ভেতরে কিছু ফরওয়ার্ড করে না। এগজিট নিজেই হাবে ডায়াল করে। ভোক্তার ট্রাফিক ল্যাপটপে টানেলে ঢোকে ও এগজিটের আপলিংক দিয়ে বেরোয়। বিস্ময়কর সবকিছু এক বিবরণ থেকে আসে: সংযোগ এগজিটই শুরু করেছে, তাই ভেতরের পথ আগেই আছে, পোর্ট ফরওয়ার্ড লাগে না।

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

দুটি ট্রান্সপোর্ট সেশন, একটি ভেতরের পথ

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

outer: consumer --TLS--> hub
outer: exit     --TLS--> hub
inner: consumer --tun--> hub --internal--> exit --tun--> uplink

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

iroute আসলে সার্ভারে কী ইনস্টল করে

হাবই একমাত্র ডিভাইস যা ঠিক করে কোন পিয়ার কোন গন্তব্যের মালিক, এবং তা কার্নেলের নয়, নিজের ইউজারস্পেস রাউটিং টেবিলে। এগজিটের জন্য exit-node নামের client-config-dir এন্ট্রি সেখানে ডিফল্ট প্রিফিক্স দাবি করতে পারে:

# /etc/openvpn/server/ccd/exit-node
iroute 0.0.0.0 0.0.0.0

এই লাইন সার্ভার প্রসেসকে বলে "যেকোনো গন্তব্যের ভেতরের প্যাকেট এই ক্লায়েন্টের"। এটি হাবের OS-এ ডিফল্ট রুট যোগ করে না, হাবকে ইন্টারনেট গেটওয়েও বানায় না। OpenVPN 2.6 রেফারেন্স ক্লায়েন্ট-নির্দিষ্ট রাউটিং ও কার্নেল রাউটিংকে আলাদা প্রক্রিয়া রাখে, আর এই বিচ্ছেদই হাবের ডিফল্ট রুট না ছুঁয়ে নকশাটিকে কাজ করতে দেয়।

ভোক্তার বিপরীত নির্দেশনা দরকার, push হিসেবে, যাতে তার ট্রাফিক স্থানীয় গেটওয়ে দিয়ে না গিয়ে টানেলে ঢোকে। সাবনেট টপোলজিতে পুলটি এগজিটের tun ডিভাইসে সংযুক্ত রুট, তাই ফেরার দিকে push লাগে না; এগজিট যা পাবে না তা হলো নিচের রিডাইরেকশন, যা তার আপলিংক ট্রাফিককে যে টানেল ব্যবহার করতে চাইছে সেটিতেই ফেরত পাঠাবে। এটি কেবল ভোক্তাকে পাঠান, আর CCD ফাইল বেছে নেওয়া হয়েছে বলে ভরসা না করে ক্লায়েন্টে প্রয়োগ করা রুট পড়ুন।

# /etc/openvpn/server/ccd/consumer-01
push "redirect-gateway def1"

ফরওয়ার্ডিং করে এগজিটের কার্নেল

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

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

সোর্স অনুবাদই রিটার্ন পাথ কিনে দেয়

ইন্টারনেট হোস্টের 10.90.0.x ঠিকানায় রুট নেই, তাই উত্তর এগজিটে পৌঁছানোর আগেই বাদ পড়ত। প্যাকেট আপলিংক ছাড়ার সময় সোর্স পুনর্লিখন করলে তা সমাধান হয়, আর কানেকশন ট্র্যাকিং ফেরার পথে তা উল্টে দেয়।

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o enp1s0 -j MASQUERADE
ip -4 route get 10.90.0.9   # run on the exit: must point at the tun

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

হাব কোথায় প্রয়োগ করতে পারে, কোথায় পারে না

client-to-client ও প্রচলিত ইউজারস্পেস ডেটা পাথের সঙ্গে হাব সার্ভার প্রসেসের ভেতরেই পিয়ারদের মধ্যে প্যাকেট হস্তান্তর করে। সেগুলো কখনো হাবের কার্নেল FORWARD চেইন অতিক্রম করে না, তাই সেখানে কার্নেল নিয়ম যতই সাবধানে লেখা হোক পিয়ার-টু-পিয়ার ট্রানজিট সীমিত করতে পারে না। প্রয়োগকে সার্ভারের নিজের নীতিতেই থাকতে হবে: কে সংযোগ করতে পারবে, কোন CCD ফাইল পাবে, এবং এগজিটের ডিফল্ট মালিকানা আদৌ দেওয়া হয় কি না।

সেজন্যই ডিফল্ট iroute বিস্তৃত আস্থার সিদ্ধান্ত। এগজিটকে যেকোনো ইন্টারনেট ঠিকানা থেকে ফেরত ট্রাফিক বৈধভাবে নিতে হয়, এবং এটি এমন মেশিন হতে হবে যা আপনি নিয়ন্ত্রণ, প্যাচ ও পর্যবেক্ষণ করেন। একই মালিকানা এমন পিয়ারকে দেওয়া, যাকে আপনি রাউটার দিতেন না — এটাই সেই ভুল যা এই নকশা আমন্ত্রণ জানায়।

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

এগজিট হারালে নিরাপদে ব্যর্থ হওয়া

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

# on the consumer, with the exit up and then down
ip -4 route get 1.1.1.1
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

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