VPN ক্লায়েন্ট ও LAN: কখন আলাদা জোন ব্যবহার করবেন

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

জোনের নাম কিছুই এনক্রিপ্ট করে না বা ব্যবহারকারীকে প্রমাণিত করে না। এটি কেবল ফায়ারওয়ালের নীতিমালার মডেলের জন্য ইন্টারফেসগুলোকে দলবদ্ধ করে।

জোন সদস্যতা আসলে কী নিয়ন্ত্রণ করে

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

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

এই পার্থক্যই আলাদা জোনের উপকারিতার কারণ: আপনি প্রতিটি দিক ও প্রতিটি ভূমিকা স্পষ্টভাবে উল্লেখ করতে পারেন। প্রতিটি নিয়মের পাশে দিকটি লিখুন।

সিদ্ধান্ত এক: ইনপুট, ফরওয়ার্ড, নাকি উভয়ই

দূরবর্তী ক্লায়েন্টদের রাউটার থেকে DNS দরকার হলে কেবল সেই সেবার জন্য ইনপুট অনুমোদন করুন। তাদের ফাইল সার্ভারে পৌঁছাতে হলে সেই গন্তব্যে ফরওয়ার্ড অনুমোদন করুন। বেশিরভাগ VPN নকশায় দুটোই দরকার, তবে ভিন্ন ভিন্ন সেবার জন্য।

প্রতিটি স্থানীয় সেবায় বিস্তৃত ইনপুট অ্যাক্সেস প্রায় কখনো প্রয়োজন হয় না। রাউটার ব্যবস্থাপনাকে অ্যাপ্লিকেশন অ্যাক্সেস থেকে আলাদা সিদ্ধান্ত হিসেবে দেখুন। রাউটারকে কেবল DNS-এর উত্তর দিতে হলে ওই একটি অনুমতি লিখুন এবং বাকিটা বন্ধ রাখুন।

সিদ্ধান্ত দুই: দূরবর্তী ক্লায়েন্টদের কোন সম্পদ দরকার

নিয়ম লেখার আগে ক্লায়েন্ট রেঞ্জ, গন্তব্য এবং VPN-এর দেওয়া উচিত এমন সেবাগুলো তালিকাভুক্ত করুন। গন্তব্যের তালিকা বিশ্বাসের লেবেলের চেয়ে বেশি কাজে লাগে, কারণ এটি ফায়ারওয়াল স্থানান্তরেও টিকে থাকে।

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

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

সিদ্ধান্ত তিন: আপনি কীভাবে সীমান্ত প্রমাণ করবেন

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

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

নেটওয়ার্ক বাড়লে সদস্যতা ও নিয়মের উদ্দেশ্য নথিভুক্ত করুন। কেউ সুবিধাজনক জোনের নাম দিয়েছে বলে একটি নতুন সংযুক্ত ইন্টারফেস বিশেষাধিকার উত্তরাধিকার সূত্রে পাবে না।