OPNsense-এর পেছনে OpenVPN ক্লায়েন্টের স্থির ঠিকানা

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

OPNsense এই ওভাররাইডগুলো সার্ভারের ক্লায়েন্ট-নির্দিষ্ট সেটিংসে রাখে, সার্টিফিকেটের কমন নেম দিয়ে চাবিকৃত, যা কমন নেমকে ঠিকানা পরিকল্পনার অংশ করে তোলে।

আঠালো লিজ কোনো স্থির ঠিকানা নয়

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

ডায়নামিক বিকল্পটি, অর্থাৎ client-connect স্ক্রিপ্ট ও ডায়নামিক আপডেট দিয়ে VPN-কে DNS-এ যুক্ত করা, কাজ করে এবং এমন রিজলভার দরকার যেটি আপডেট গ্রহণ করে, সাথে প্রতিটি সংযোগে একটি স্ক্রিপ্ট। অ্যাপ্লায়েন্সে আপনি ভেন্ডরের দেওয়া প্যাকেজেই সীমাবদ্ধ, আর সাধারণত ঠিক সেখানেই ওই পরিকল্পনা থেমে যায়।

যে /30 হিসাব কেউ উপভোগ করে না

ডিফল্ট net30 টপোলজিতে প্রতিটি ক্লায়েন্ট নিজের /30 পায়: প্রথম ব্যবহারযোগ্য ঠিকানা সার্ভারের দিকে যায়, দ্বিতীয়টি ক্লায়েন্টের কাছে। তাই ওভাররাইডগুলোকে সার্ভারের ডায়নামিক টানেল নেটওয়ার্কের বাইরে থাকতে হবে, যার মানে আগে সেই নেটওয়ার্ক প্রশস্ত করা। 10.8.0.0/24-এ থাকা সার্ভার 10.8.0.0/23-এ যেতে পারে, পুরোনো পরিসরের অর্ধেক ডায়নামিক ক্লায়েন্টের জন্য আর বাকি অর্ধেক ওভাররাইডের জন্য রেখে। মূল /24-টি অতিরিক্ত IPv4 লোকাল নেটওয়ার্ক হিসেবে যোগ করুন, যাতে দুই অর্ধের ট্রাফিকই টানেলে রুট হয়।

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

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

লোকাল নেটওয়ার্ক আর ক্লায়েন্টরা যে জোনে কোয়েরি করে

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

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

নতুন সংযোগে কী যাচাই করবেন

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

ভিন্ন কমন নেমে পুনরায় ইস্যু করা সার্টিফিকেট তার ওভাররাইডের সাথে মেলা বন্ধ করে ক্লায়েন্টকে ডায়নামিক পুলে ফিরিয়ে দেয়। যেকোনো পরিচয় পরিবর্তনের পর এটি আশা করুন।