মাস্কারেড নাকি নীতি-ভিত্তিক রাউটিং: VPN গেটওয়ে দিয়ে LAN ট্রাফিক

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

দুই নকশা ভিন্ন ভিন্ন প্রতিশ্রুতি দেয়

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

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

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

মাস্কারেড: দূরপ্রান্তে একটিই পিয়ার

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

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

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

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

নীতি-ভিত্তিক রাউটিং: উৎস রাখুন, একটি ফিরতি পথ যোগ করুন

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

ip rule add iif eth1 table vpn
ip route add default dev tun0 table vpn

এরপর দূরপ্রান্তকে LAN প্রিফিক্স টানেল দিয়ে ফিরিয়ে রাউট করতে হবে। এটি এই গেটওয়েতে নয়, দূরবর্তী রাউটারে একটি কনফিগারেশন। গেটওয়েকে এমন ইন্টারফেসে আসা উত্তরও গ্রহণ করতে হবে যা মূল টেবিল প্রত্যাশা করত না; কঠোর মোড ওই প্যাকেটগুলো ফেলে দিলে শিথিল বিপরীত-পথ ফিল্টারিং (rp_filter 2 এ সেট) স্বাভাবিক সমন্বয়।

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

মালিকানা ও দূরপ্রান্ত কী লগ করে তার ভিত্তিতে সিদ্ধান্ত নিন

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

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

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

এক ক্লায়েন্ট থেকে যাচাই করুন, তারপর দ্বিতীয় ক্লায়েন্ট থেকে

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

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

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