দুটি ডিভাইস, একটি OpenVPN সার্টিফিকেট: পুনঃসংযোগের চক্র

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

রিস্টার্টের ব্যবধান থেকেই শুরু করুন

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

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

ব্যবধান ও কারণ লিখে রাখুন। দুটোই প্রমাণ, আর দুটোই সস্তায় সংগ্রহ করা যায়।

সার্ভার দ্বিতীয় লগইন সম্পর্কে কী বলেছে তা পড়ুন

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

হোস্টেড সেবায় আপনার কোনো সার্ভার লগই না থাকতে পারে। তখন সূত্র হলো সময়: অন্য মেশিন সংযোগ করলেই যে স্থিতিশীল টানেল পড়ে যায়, আর ক্লায়েন্ট লগে টাইমআউট ছাড়া কিছুই থাকে না।

কেবল দূরবর্তী হোস্টনেম নয়, দুটি প্রোফাইলের সার্টিফিকেট ও কী ব্লক মিলিয়ে দেখুন। কপি করা প্রোফাইল সাধারণত কেবল ফাইলের নামেই আলাদা হয়।

সার্ভারের দিকে পরিচয়টি আলাদা করুন

এই সার্ভারের জন্য সাইন করা CA-এর মাধ্যমে প্রতিটি ডিভাইসের জন্য একটি সার্টিফিকেট ইস্যু করুন। Easy-RSA-তে এর অর্থ প্রতিটি ডিভাইসের জন্য আলাদা ক্লায়েন্ট নাম, এবং এরপর সেই সার্টিফিকেট ও তার কী থেকে প্রোফাইল তৈরি হয়। কমন নেইম ডিভাইসের পরিচয় হয়ে ওঠে, যা ঠিক সার্ভারের অনুপস্থিত ছিল। ব্যক্তির বদলে ডিভাইসের নামে নাম দিন, যাতে প্রতিস্থাপনে নতুন নাম তৈরি হয়।

শেয়ার করা কন্ট্রোল-চ্যানেল কী আলাদা বিষয়। tls-crypt বা tls-auth প্রতিটি ক্লায়েন্টের কন্ট্রোল চ্যানেল রক্ষা করে এবং শেয়ার করার জন্যই বানানো। এটি ক্লায়েন্ট পরিচয় নয়, আর এটি বদলালে ডুপ্লিকেট সার্টিফিকেট ঠিক হবে না।

সার্টিফিকেট, কী এবং প্রতি-ক্লায়েন্ট কনফিগারেশন ফাইল একই কমন নেইমে রাখুন, নইলে পরের সংযোগেই ম্যাপিং ভেঙে যায়। সেখানে অমিল থাকলে ক্লায়েন্ট প্রমাণীকরণ পেরিয়ে কিছুই পায় না।

বিভাজনের পরে ঠিকানা ও সেটিংস মিলিয়ে রাখুন

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

সার্টিফিকেটের সঙ্গেই ম্যাপিং হালনাগাদ করুন, তারপর দুটি ডিভাইস আবার সংযুক্ত করে তাদের বরাদ্দ ঠিকানা মিলিয়ে দেখুন। ডুপ্লিকেট ঠিকানা পরিষ্কার পুনঃসংযোগের বদলে থেমে থেমে ক্ষতি হিসেবে দেখা দেয়।

প্রতি ডিভাইসে আলাদা হওয়া উচিত সেটিংস সেই ডিভাইসের নিজস্ব ফাইলের মাধ্যমে পাঠান, শেয়ার করা টেমপ্লেট দিয়ে নয়। শেয়ার করা টেমপ্লেট পরের ডুপ্লিকেটটি ধরাও কঠিন করে তোলে।

পুরোনো পরিচয় যথাযথভাবে প্রত্যাহার করুন

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

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