কেন বড় OpenVPN কী রিকি টাইমার সরিয়ে দেয় না

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

সাইফার ছোঁয়ার আগে রিকি সেটিংস পড়ুন, এবং তা করার সময় দুই প্রান্তই পড়ুন।

কী-এর শক্তি আর কী-এর আয়ু ভিন্ন প্রশ্নের উত্তর দেয়

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

ডিপ্লয়মেন্ট নোটে দুটোই লিখুন: ডেটা চ্যানেল কী রক্ষা করে, আর তার কী কখন প্রতিস্থাপন ঘটায়।

রিকির তিনটি ট্রিগার আছে, এবং যেকোনো প্রান্ত তা চালু করতে পারে

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

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

রিকি প্রমাণীকরণ প্রবাহকে প্রকাশ করে

পুনর্বিবাদ মানে নতুন TLS হ্যান্ডশেক, অর্থাৎ প্রমাণীকরণের পথ আবার চলে। এককালীন কোড, হার্ডওয়্যার টোকেন বা RADIUS চ্যালেঞ্জ ব্যবহার করা ডিপ্লয়মেন্ট এটি কঠিনভাবে জানতে পারে: প্রথম সংযোগ কাজ করে, আর এক ঘণ্টা পরে সেশন মরে যায় যখন দ্বিতীয় হ্যান্ডশেক আগেই ব্যবহৃত কোড চায়। auth-gen-token ওই ফাঁক পূরণের জন্য আছে, যাতে সার্ভার নতুন ইন্টারঅ্যাকটিভ লগইন দাবি না করে পুনর্বিবাদের জন্য স্বল্পস্থায়ী টোকেন দিতে পারে।

একে অপারেটরের সঙ্গে সমাধান করার প্রবাহ-সমস্যা হিসেবে ধরুন, নবায়ন বন্ধ করা উচিত এর প্রমাণ হিসেবে নয়।

নবায়ন লোডের মধ্যে পরীক্ষা করুন, এক মিনিটের সেশনে নয়

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

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

দুটি পছন্দই নথিভুক্ত করুন

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

সামঞ্জস্য ব্যতিক্রম বাধ্য করলে তা একটি সংস্করণ ও একটি শেষ তারিখে সীমাবদ্ধ করুন। যে ব্যতিক্রম নিজের কারণের চেয়ে বেশি বাঁচে, সেটিই সেই নীতি হয়ে যায় যা কেউ মনে করে না সে বেছে নিয়েছিল।