OpenBSD VPN গেটওয়েতে tun0 দিয়ে LAN-এর NAT

একই OpenBSD গেটওয়ে পাওয়া দুই ইঞ্জিনিয়ার প্রায়ই দূরবর্তী নেটওয়ার্কে পৌঁছানোর জন্য আপনাকে দুটি ভিন্ন নিয়ম-সেট দেবেন, আর দুটিই যুক্তিসঙ্গত। সোর্স ট্রান্সলেশন আর রিটার্ন রুটের মধ্যে বেছে নেওয়া আদৌ কোনো সিনট্যাক্স প্রশ্ন নয়। এটি নির্ভর করে দূরবর্তী দিকটি 192.168.88.0/24 সম্পর্কে ইতিমধ্যে কী জানে এবং আপনার লগে কী রাখতে হবে তার উপর। এটি ভুল করলে nat-to লাইনটি নিখুঁতভাবে সঠিক দেখাবে, অথচ উত্তরগুলি দূরবর্তী ডিফল্ট গেটওয়েতে হারিয়ে যাবে।

রাউটিং এবং পুনর্লিখন ভিন্ন প্রশ্নের উত্তর দেয়

রাউটিং টেবিল সিদ্ধান্ত নেয় যে 172.20.0.0/16 tun0 দিয়ে পৌঁছানো যায়, এবং সেই সিদ্ধান্ত কোনো pf ট্রান্সলেশনে পরামর্শ করার আগেই নেওয়া হয়। তারপর সোর্স ট্রান্সলেশন প্যাকেট হেডার বদলায় যাতে দূরবর্তী প্রান্ত LAN হোস্টের বদলে গেটওয়ের টানেল ঠিকানা দেখে। কোনো একটি প্রক্রিয়া অন্যটির বিকল্প নয়: nat নিয়ম শূন্য থেকে রুট তৈরি করতে পারে না, আর রুট এমন দূরবর্তী রাউটারকে বোঝাতে পারে না যে কখনও আপনার প্রাইভেট সাবনেটের কথা শোনেনি। দূরবর্তী দিকে রিটার্ন পাথ না থাকলে উত্তরগুলি ফেলে দেওয়া হয় বা তার ডিফল্ট গেটওয়েতে পাঠানো হয়, আর কোনো নিয়ম-সামঞ্জস্য তা ঠিক করে না।

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

তিনটি শর্ত যা এটি নির্ধারণ করে

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

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

অংশটিকে এমন জায়গায় রাখুন যেখানে pf সত্যিই এটি মূল্যায়ন করবে

নিচের অংশটি ধরে নেয় LAN হল 192.168.88.0/24, দূরবর্তী নেটওয়ার্ক 172.20.0.0/16, এবং টানেল ইন্টারফেস tun0। এতে কিছুই পরবর্তী হপ বেছে নেয় না। এটি কেবল সেই প্যাকেটগুলিতে সোর্স পুনর্লিখন করে যেগুলি ইতিমধ্যে টানেল দিয়ে বেরোচ্ছে।

match out on tun0 inet from 192.168.88.0/24 to 172.20.0.0/16 nat-to (tun0)
pass in on em0 inet from 192.168.88.0/24 to any keep state

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

কার্নেলের দিকটি ভুলবেন না। IPv4 ফরওয়ার্ডিং সক্ষম করতে হবে, এবং টানেল ও LAN-এর স্টেটফুল pass নিয়মগুলি এর কোনো অর্থ হওয়ার আগে থাকতে হবে। OpenBSD FAQ-র PF NAT বিভাগ এখানে কীওয়ার্ডের ক্রমের জন্য সঠিক রেফারেন্স।

ট্র্যাফিককে বিশ্বাস করার আগে নিয়ম-সেট যাচাই করুন

প্রথমে pfctl -nf /etc/pf.conf দিয়ে সিনট্যাক্স পরীক্ষা করুন, যা ফাইলটি লোড না করেই পার্স করে। তারপর নীতিটি লোড করুন এবং কার্নেল আসলে কী ধরে আছে তা পড়ে দেখুন, কারণ একটি নিয়ম যে পরিষ্কারভাবে পার্স হয়েছে তবুও ছায়াবৃত হতে পারে বা ভুল ইন্টারফেসে সংযুক্ত হতে পারে। pfctl -sn ট্রান্সলেশন নিয়মগুলি লোড করা আকারে ছাপে, আর pfctl -sr ফিল্টার নিয়মগুলি মূল্যায়ন ক্রমে ছাপে।

এরপর তারটি দেখুন। গেটওয়েতে tcpdump -ni tun0 'host 172.20.0.10' দেখায় টানেল ছেড়ে যাওয়া সোর্স ঠিকানাটি টানেল ঠিকানা না LAN হোস্ট। একটি দ্রুত netstat -rn -f inet নিশ্চিত করে গন্তব্যটি কোন ইন্টারফেসে সমাধান হয়। ট্র্যাফিক চলতে শুরু করলে pfctl -ss স্টেট এন্ট্রি তালিকাভুক্ত করে; যদি কোনো প্রবাহ কোনো স্টেট তৈরি না করে, প্যাকেটটি কখনও সেই নিয়মের সাথে মেলেনি যা একটি তৈরি করে।

যদি টানেলের দিকটি ঠিক দেখায় এবং উত্তরগুলি তবুও কখনও না আসে, pf সম্পাদনা করা বন্ধ করুন। বাকি ব্যর্থতা দূরবর্তী রাউটারে, যেখানে উত্তরটি এমন একটি প্রাইভেট ঠিকানার দিকে পাঠানো হচ্ছে যা ওই দিক পৌঁছাতে পারে না।

যখন ট্রান্সলেশন যা বাঁচায় তার চেয়ে বেশি খরচ করে

ট্রান্সলেশন ক্লায়েন্টদের লুকায়, আর মাঝে মাঝে সেটিই ভুল লেনদেন। ওভারল্যাপিং সাবনেট একটি ক্ষেত্র: যদি দূরবর্তী দিকও অভ্যন্তরীণভাবে 192.168.88.0/24 ব্যবহার করে, LAN হোস্টগুলিকে গেটওয়ে হিসেবে উপস্থাপন করা সংঘর্ষকে আরও খারাপ করে, ভালো নয়। IPsec নীতিগুলি যা ঠিকানা জোড়া দিয়ে ট্র্যাফিক নির্বাচন করে তা আরেকটি, কারণ নিরাপত্তা নীতি ডেটাবেস ট্রান্সলেশনের আগে মিলিত হয় এবং আপনার পুনর্লিখিত প্যাকেট কখনও দেখে না। যে কোনো স্থাপনা যা প্রতি ব্যবহারকারীর জন্য বিল করে, থ্রটল করে বা অডিট করে, সেটিও তার প্রয়োজনীয় পরিচয় হারায় যেই মুহূর্তে সোর্স একটি ঠিকানায় সংকুচিত হয়।

পোর্টেবল pf ডেরিভেটিভগুলি আলাদা ফাঁদ। যে পণ্যগুলি নিজের নিয়ম ফাইল তৈরি করে তারা আশা করে NAT তাদের ইন্টারফেস দিয়ে কনফিগার হবে, আর হাতে সম্পাদিত অংশগুলি পরবর্তী রিলোডে ওভাররাইট হয়। match কীওয়ার্ডের অস্তিত্বের আগে লেখা গাইড থেকে কপি করা নিয়ম-সেট বর্তমান কার্নেলে লোড হবে না, তাই সিনট্যাক্সটি পোর্ট করুন এবং অনুমান না করে ত্রুটিটি পড়ুন।

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