একটি LAN সাবনেট OpenVPN দিয়ে রুট করুন আর ডিফল্ট ধরে রাখুন
একটি সাবনেট টানেল দিয়ে চলুক, আর LAN ডিফল্ট ধরে রাখুন। পলিসি টেবিলের সঙ্গে মেইন টেবিলের সম্পাদনা তুলনা করুন, তারপর NAT না সার্ভার-সাইড রুট বেছে নিন।
যে বাক্সগুলো LAN-এর জন্য রাউট করে আর একইসঙ্গে VPN ডায়াল করে, তারা নিজেদের সঙ্গে একই তর্কে পড়ে যায়: টানেল ডিফল্ট রুটটির মালিক হতে চায়, আর LAN সেটি ফিরে চায়। OpenVPN সংযোগ করলে এটি টানেলের মধ্য দিয়ে একটি ডিফল্ট বা দুটি অর্ধ-ডিফল্ট বসাতে পারে, যা ল্যাপটপের জন্য ঠিক কিন্তু এমন গেটওয়ের জন্য ভুল যার প্রতিবেশীরা তার LAN ঠিকানা থেকে উত্তর আশা করে। উত্তরটি VPN বাদ দেওয়া নয়। উত্তরটি হলো দুটি সিদ্ধান্তকে দুটি আলাদা টেবিল দেওয়া।
একটি ডিফল্ট রুট, দুই মালিক
ফরওয়ার্ড করা ট্র্যাফিক আর স্থানীয়ভাবে তৈরি ট্র্যাফিককে একই পথ নিতে হয় না। LAN ক্লায়েন্টদের টানেল দরকার শুধু আপনার বেছে নেওয়া গন্তব্যগুলোর জন্য, অন্যদিকে হোস্টের নিজের ব্যবস্থাপনা সেশন আর সেই ক্লায়েন্টদের প্রতি তার উত্তরগুলোর দরকার LAN ডিফল্ট। দুটোকে মেইন টেবিলে মেশালে দুটি ভিন্ন প্রশ্নের উপর একটিই উত্তর চাপিয়ে দেওয়া হয়।
OpenVPN-এ ঠিক এই কাজের জন্য একটি সুইচ আছে। route-noexec ক্লায়েন্টকে মেইন টেবিল স্পর্শ করা থেকে একেবারে বিরত রাখে, আর যে মানগুলো এটি ব্যবহার করত সেগুলো route-up স্ক্রিপ্টে route_vpn_gateway, dev এবং ইন্টারফেসের ঠিকানা হিসেবে পাঠানো হয়। এরপর কোন টেবিল কোন রুট পাবে তা আপনি ঠিক করেন, এমন কোডে যা পরে পড়া যাবে।
পলিসি টেবিল বনাম মেইন টেবিল পুনর্লিখন
| Approach | What it buys | What it costs |
|---|---|---|
| Separate table plus source rule | LAN traffic and host traffic keep independent defaults | Every lookup now depends on rule order |
| Editing the main table only | Fewer moving parts on a single-purpose host | One mistake takes the gateway offline entirely |
| Two half-default routes | Works for a full-tunnel client | Ambiguous on a host that must answer on its LAN address |
আলাদা টেবিলই একমাত্র বিকল্প যা এক সাবনেটের বেশি পর্যন্ত স্কেল করে। একবার এর নাম দিন, তারপর নাম ধরেই উল্লেখ করুন যাতে কাউকে কোনো সংখ্যা মনে রাখতে না হয়:
echo "10 vpn" >> /etc/iproute2/rt_tables
ip rule add from 192.168.50.0/24 table vpn
ip route add default via 10.8.0.1 dev tun0 table vpnএখানকার ঠিকানাগুলো প্লেসহোল্ডার। কিছু চালানোর আগে আপনার নিজের স্থাপনা থেকে LAN প্রিফিক্স, টানেল গেটওয়ে আর ডিভাইসের নাম বসিয়ে নিন।
নিয়মটিকে হোস্টের সঙ্গেও মেলাতে হবে
শুধু LAN প্রিফিক্সের সঙ্গে মেলে এমন নিয়ম ফরওয়ার্ড করা প্যাকেট কভার করে। এটি গেটওয়ে নিজে যেসব ট্র্যাফিক তৈরি করে তা কভার করে না, আর LAN ক্লায়েন্টদের ফেরত দেওয়া উত্তরও কভার করে না, যে উত্তরগুলো উৎস হিসেবে গেটওয়ের LAN ঠিকানা বহন করে। সেই লুকআপগুলো main-এ গিয়ে পড়ে এবং এখনও টানেল দিয়ে বেরিয়ে যেতে পারে।
গেটওয়ের নিজের LAN ঠিকানার জন্য দ্বিতীয় একটি নিয়ম যোগ করুন, বা প্রথম নিয়মটিকে দুটোই ধরার মতো একটি সেটে প্রশস্ত করুন। ক্রমটি গুরুত্বপূর্ণ: বেশি নির্দিষ্ট নিয়মটি আগে রাখুন, আর উৎস স্পষ্টভাবে উল্লেখ করা একটি লুকআপ দিয়ে ফলাফল যাচাই করুন।
ip route get 203.0.113.9 from 192.168.50.1যদি সেটি স্থানীয় থাকা উচিত এমন গন্তব্যের জন্য টানেল ডিভাইস দেখায়, তবে টেবিলে কী আছে তা নির্বিশেষে নিয়মের সেটটি ভুল।
NAT না ওপারের রুট
VPN সার্ভার টানেল সাবনেট জানে আর কিছুই জানে না। LAN উৎস ঠিকানা নিয়ে আসা প্যাকেটের ফেরার পথ থাকে না, যদি না কেউ সেটি দেয়, আর সেটি দেওয়ার ঠিক দুটি উপায় আছে। সার্ভারে LAN প্রিফিক্সের জন্য একটি রুট যোগ করলে মূল উৎস প্রান্ত থেকে প্রান্ত পর্যন্ত দৃশ্যমান থাকে, যা নিরীক্ষিত নকশা সাধারণত চায়। গেটওয়েতে মাস্কারেড করলে উৎসকে টানেল ঠিকানায় পুনর্লিখন করা হয় এবং সার্ভারের কোনো সহযোগিতা লাগে না।
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADEসার্ভার নিয়ন্ত্রণ না করলে এবং সেখানে রুট যোগ করতে না পারলে NAT বেছে নিন। লগ, অ্যাক্সেস নিয়ন্ত্রণ বা ফেরার পথের প্রতিসাম্য গুরুত্বপূর্ণ হলে সার্ভার-সাইড রুট বেছে নিন, কারণ মাস্কারেড করা ওপার যা রেকর্ড করে তার সব কিছু থেকে মূল ঠিকানা মুছে দেয়।
দুই ক্ষেত্রেই ফরওয়ার্ডিং সক্রিয় থাকতে হবে, আর কঠোর রিভার্স-পাথ ফিল্টারিং উত্তরটি ফেলে দিতে পারে যখন main ওই উৎসের জন্য টানেল বেছে নিত না। টানেলকে দোষ দেওয়ার আগে কার্যকর মানটি যাচাই করুন।
পুনঃসংযোগেও যেন বিভাজনটি টিকে থাকে
হাতে যোগ করা নিয়ম আর রুটগুলো ইন্টারফেস আবার তৈরি হলে হারিয়ে যায়, আর পুরোনো টেবিল এন্ট্রি তার যৌক্তিকতা দেওয়া সেশনকেও ছাড়িয়ে থাকতে পারে। টেবিলের নিয়ম, টানেলের রুট আর মাস্কারেড এন্ট্রি ক্লায়েন্টের route-up স্ক্রিপ্টের ভিতরে রাখুন, আর স্ক্রিপ্টের শুরুতে টেবিলটি ফ্লাশ করুন যাতে পুরোনো গেটওয়ে নতুন সেশনে টিকে থাকতে না পারে।
দুই প্রান্ত থেকেই যাচাই করুন: গেটওয়েতে LAN উৎস দিয়ে একটি লুকআপ, আর LAN ক্লায়েন্ট থেকে টানেল পার হওয়া উচিত এমন গন্তব্যে একটি প্রকৃত অনুরোধ। যে রুট আছে কিন্তু কখনো বেছে নেওয়া হয় না, কাউন্টার পড়ার আগ পর্যন্ত ঠিক রুটহীন অবস্থার মতোই আচরণ করে।