OpenVPN সার্ভার nopool: একটি স্পষ্ট পুল পরিসর ঘোষণা করুন

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

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

আপনার কাছে যে সাবনেট ইতিমধ্যে আছে সেখান থেকেই শুরু করুন

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

grep -nE '^(topology|server|ifconfig-pool|max-clients|client-config-dir)' /etc/openvpn/server/lab.conf
ip -4 addr show tun0

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

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

nopool যোগ করুন এবং পরিসর ঘোষণা করুন

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

topology subnet
server 10.70.0.0 255.255.255.0 nopool
ifconfig-pool 10.70.0.50 10.70.0.120 255.255.255.0

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

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

স্থির অ্যাসাইনমেন্ট গতিশীল পরিসরের বাইরে রাখুন

ক্লায়েন্ট-নির্দিষ্ট ifconfig-push পুল বরাদ্দ থেকে ভিন্ন একটি প্রক্রিয়া, এবং এটি সক্রিয় টপোলজির উপযুক্ত প্যারামিটার ব্যবহার করতে হবে। সাবনেট মোডে সেটি একটি ঠিকানা ও নেটমাস্ক; পুরোনো উদাহরণে দেখা গেছে বলে net30 জোড়া বহন করা একটি সাধারণ ভুল।

বরাদ্দের ইতিহাস একটি ইঙ্গিত, কর্তৃত্ব নয়। persist ফাইল মনে রাখে কোন ক্লায়েন্টের কোন ঠিকানা ছিল, তাই পুনরায় সংযোগ করা ক্লায়েন্টরা সাধারণত একই ঠিকানা পায়, এবং এটি ঠিকানা সংরক্ষণ করে না, মুক্ত করে না, বা স্থির অ্যাসাইনমেন্ট প্রতিস্থাপন করে না। নির্দিষ্ট ডিভাইসকে যদি সবসময় নির্দিষ্ট ঠিকানা ধরে রাখতে হয়, persist ফাইলের উপর নির্ভর না করে স্থির অ্যাসাইনমেন্ট ব্যবহার করুন।

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

জীবনচক্রের মাধ্যমে প্রয়োগ করুন, তারপর যাচাই করুন

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

systemctl restart openvpn-server@lab
journalctl -u openvpn-server@lab -n 30 --no-pager
# on a fresh client
ip -4 addr show tun0

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

পুরোনো পরিসর থেকে ঠিকানা ধরে রাখা একটি ক্লায়েন্ট আবার সংযুক্ত করুন। এটির নতুন পরিসর থেকে ঠিকানা পাওয়া উচিত, এবং পুরোনো ঠিকানার সঙ্গে যুক্ত যেকোনো সেশন-স্তরের অবস্থা চলে যাওয়া উচিত। যদি এটি পুরোনো ঠিকানা ধরে রাখে, তবে অন্য কিছু এটি বরাদ্দ করছে এবং পুল আপনার ভাবা মালিক নয়।

পরিসর পরিবর্তন রোলব্যাক করা

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

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

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