স্থিতিশীল OpenVPN ঠিকানাগুলো উৎস IP নয়, পরিচয় অনুসরণ করা উচিত

যে ঠিকানা পরিকল্পনা বলে ‘এই ল্যাপটপ 10.90.0.10 পায়’, সেগুলো আসলে পরিচয় সম্পর্কে বিবৃতি: কোন প্রমাণিত ডিভাইস ওই ঠিকানা ধারণ করতে পারে। ওই ডিভাইসের বর্তমান পাবলিক IP-এর সঙ্গে এর প্রায় কোনো সম্পর্ক নেই, কারণ NAT এবং রোমিং ব্যবহারকারী কে তা না বদলেই এটি বদলে দেয়। উৎস ঠিকানার উপর পরিকল্পনা গড়লে এমন নিয়ম তৈরি হয় যা প্রথম হোটেল নেটওয়ার্কেই ভেঙে পড়ে। প্রমাণিত পরিচয়ের উপর এটি গড়লে এমন পরিকল্পনা তৈরি হয় যা ভ্রমণে টিকে থাকে।

সার্ভার কী যাচাই করতে পারে তা দিয়ে শুরু করুন, তারপর ঠিকানাটি কীসের জন্য তা ঠিক করুন।

ঠিকানার আগে পরিচয়ের কী বেছে নিন

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

duplicate-cn থাকলে একাধিক একসঙ্গে চলা সেশন একই সাধারণ নাম উপস্থাপন করতে পারে, তাই একটি পিন করা ঠিকানা তাদের আলাদাভাবে শনাক্ত করতে পারে না। এটি পরিচয় মডেলের একটি বৈশিষ্ট্য, আরও ভালো ঠিকানা পরিকল্পনা যা ঠিক করতে পারে এমন কিছু নয়।

ডাইনামিক রেঞ্জের বাইরে ঠিকানা সংরক্ষণ করুন

10.90.0.0/24-এর মতো সাবনেট-টোপোলজি নেটওয়ার্কে নামযুক্ত সদস্যদের জন্য নিচের ঠিকানাগুলো রাখুন এবং ডাইনামিক পুলটি আলাদা রেঞ্জে রাখুন। একটি পিন করা সদস্যের বরাদ্দ দেখতে এমন: ifconfig-push 10.90.0.10 255.255.255.0, যে ফাইলটি সার্ভার ওই পরিচয়ের জন্য বেছে নেয়। দ্বিতীয় আর্গুমেন্টটি net30-এ ভিন্ন কিছু বোঝায়, তাই উদাহরণটি টোপোলজি-নিরপেক্ষ নয়। কপি করার আগে টোপোলজি পড়ুন।

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

বরাদ্দের অগ্রাধিকার ঠিক করে কে জিতবে

ম্যানুয়াল একটি ক্রম নথিভুক্ত করে: client-connect চলাকালে তৈরি স্পষ্ট বরাদ্দ client-config-dir এন্ট্রির আগে কার্যকর হতে পারে, যা আবার সাধারণ পুল বরাদ্দের আগে আসে। এই ক্রমটি ‘পিন করা ঠিকানা প্রয়োগ হয়নি’—এমন বেশিরভাগ রিপোর্ট ব্যাখ্যা করে। এর অর্থ আরও এই যে, প্রতি-সেশন কনফিগারেশন লেখা একটি ডাইনামিক বরাদ্দকারী আপনার করা কর্তৃত্বপূর্ণ স্থির ফাইলকে নীরবে অগ্রাহ্য করতে পারে।

বরাদ্দের মালিকানা এক স্তরকে দিন এবং বাকিগুলোকে কেবল-পাঠযোগ্য করুন। যে দুটি স্তরই সিদ্ধান্তের দাবি করে তারা সময়-নির্ভর বরাদ্দ তৈরি করে।

ডাইনামিক বরাদ্দকারীরও একই মডেল দরকার

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

বরাদ্দকারীর অবস্থা সেখানেই রাখুন যেখানে পরের অপারেটর তা পড়তে পারে, এবং কেবল ঠিকানা নয়, পরিচয়-থেকে-ঠিকানা সিদ্ধান্তটি লগ করুন।

ঠিকানাটি নীতি না সুবিধা, তা ঠিক করুন

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

প্রতিটি এন্ট্রির জন্য মালিকসহ পরিকল্পনাটি একটি তালিকা হিসেবে লিখুন, তারপর একটি ডিভাইস অবসরে গেলে তা পর্যালোচনা করুন। অব্যবহৃত সংরক্ষণটিই দুর্ঘটনাক্রমে পুনরায় ব্যবহৃত হয়।