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

লক্ষণ: গেস্টরা এখনও WAN দিয়েই বেরোয়

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

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

ধাপ 1: শুধু নাম নয়, সত্যিকারের সেগমেন্ট

SSID-এর নাম বিচ্ছিন্নতা তৈরি করে না। যাচাই করুন যে গেস্ট নেটওয়ার্ক নিজের ইন্টারফেস, VLAN বা ব্রিজে শেষ হয়, এবং ঠিকানা-রেঞ্জ বিশ্বস্ত LAN থেকে আলাদা। অনেক কনজিউমার অ্যাক্সেস পয়েন্টে গেস্ট SSID বাকি সবকিছুর সঙ্গে একই সেগমেন্টে ব্রিজ করা থাকে, যার ফলে এটা ঠিক করার আগে বাকি কাজ অসম্ভব।

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

VPN সহজে কনফিগার করতে গেস্টদের মূল LAN-এ ব্রিজ করবেন না। এতে আপনি যে বিচ্ছিন্নতা চেয়েছিলেন তা রুটের শর্টকাটের সঙ্গে বদলানো হয়, আর এটাই সাধারণত গেস্ট নেটওয়ার্কের প্রিন্টার ও NAS-এ পৌঁছে যাওয়ার কারণ।

ধাপ 2: উৎস দিয়ে টানেল বাছুন

রাউটিং টেবিল গন্তব্য দিয়ে বাছা হয়, তাই যে নিয়ম বলে 0.0.0.0/0 টানেলে পাঠাও, তা সবার জন্য প্রযোজ্য। পলিসি রাউটিং দ্বিতীয় মাত্রা যোগ করে: উৎস-ঠিকানা দিয়ে টেবিল বাছুন। Linux-ভিত্তিক রাউটারে এটি একটি অতিরিক্ত নিয়ম এবং একটি নির্দিষ্ট টেবিল, আর ক্রম গুরুত্বপূর্ণ কারণ প্রথম মিলে যাওয়া নিয়মই জেতে:

ip rule add from 192.168.60.0/24 lookup 100 priority 1000
ip route add default dev wg0 table 100
ip route get 1.1.1.1 from 192.168.60.10

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

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

ধাপ 3: উত্তর-পথ ও অনুবাদ

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

nft add rule ip nat POSTROUTING ip saddr 192.168.60.0/24 oifname "wg0" masquerade

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

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

বিচ্ছিন্নতা পরীক্ষা করুন, শুধু ব্রাউজিং নয়

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

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

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

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

সম্পর্কিত নিবন্ধ