কোন OpenVPN প্যাকেটগুলি auth ডাইজেস্ট সুরক্ষিত করে?
auth অপশনটি প্রোফাইল যা ইঙ্গিত করে তার চেয়ে কম কভার করে। ডাইজেস্ট নীতি নির্ধারণের আগে চ্যানেল, AEAD কেস এবং কন্ট্রোল-চ্যানেল সুরক্ষা পর্যালোচনা করুন।
OpenVPN ডাইজেস্ট নিয়ে বেশিরভাগ বিতর্ক ভুল প্যাকেট থেকে শুরু হয়। auth SHA256 কে “শুধু যারা SHA256 দেয় এমন পিয়ার গ্রহণ করো” হিসেবে পড়া হলো প্রথম জিনিস যা ভুলে যেতে হবে। অপশনটি নির্দিষ্ট প্যাকেটের জন্য একটি ডাইজেস্টের নাম দেয়, এবং সেই প্যাকেটগুলি কোনটি তা নির্ভর করে চ্যানেলের উপর এবং সেই চ্যানেল AEAD কি না তার উপর। নিচের চারটি প্রশ্ন ক্রমান্বয়ে দেখুন; প্রতিটি সংকুচিত করে আপনার স্থাপনায় সেটিংটি কী অর্থ দিতে পারে।
সেটিংটি যে চ্যানেল রক্ষা করার কথা তা চিহ্নিত করুন
OpenVPN এর একটি কন্ট্রোল চ্যানেল আছে যা TLS হ্যান্ডশেক ট্রাফিক বহন করে এবং একটি ডেটা চ্যানেল আছে যা টানেল পেলোড বহন করে। auth ডাইজেস্ট উভয়েই ভূমিকা রাখে, কিন্তু একই ভূমিকা নয়, এবং প্রোফাইল পার্থক্যটি বিরলভাবে দৃশ্যমান করে। কনফিগ ফাইল স্পর্শ করার আগে লিখে রাখুন আপনি দুটির মধ্যে কোনটি সীমাবদ্ধ করতে চাইছেন।
নিচের টেবিলটি হলো একই অপশন প্রতিটি প্রসঙ্গে কীভাবে পড়ে তার সংক্ষিপ্ত সংস্করণ।
| Context | What the auth digest does |
|---|---|
| Data channel without AEAD | Selects the HMAC digest that authenticates each data packet |
| Data channel with AEAD, such as GCM | Unused for the data channel; the cipher authenticates its own packets |
| Control channel protected by tls-auth | Selects the HMAC digest for that protection, even when data is AEAD |
নির্ভর করার আগে ডেটা চ্যানেল AEAD কি না যাচাই করুন
যদি আলোচিত ডেটা সাইফার AES-GCM বা CHACHA20-POLY1305 হয়, তাহলে ডেটা চ্যানেল নিজেই প্রমাণায়ন করে এবং আলাদা ডাইজেস্ট আপনি যে কাজ কল্পনা করছেন তা করে না। দুটোই AEAD নির্মাণ, তাই অখণ্ডতা সেই একই ক্রিয়াকলাপে উৎপন্ন হয় যা পেলোড এনক্রিপ্ট করে। এটি কোনো অবনমন নয়, তবে এর অর্থ হলো “প্রতিটি ডেটা প্যাকেট HMAC-SHA256” হিসেবে ন্যায্যতা দেওয়া নীতি সেই টানেলে তথ্যগতভাবে ভুল। নীতি পুনর্লিখনের আগে সার্ভার লগ বা ক্লায়েন্ট স্ট্যাটাস আউটপুটে আলোচিত মান নিশ্চিত করুন।
প্রোফাইলের তালিকার বদলে প্রকৃতপক্ষে আলোচিত সাইফারটি পরীক্ষা করুন, কারণ আলোচনা সেটের অন্য সদস্যে পৌঁছাতে পারে। data-ciphers AES-256-GCM:AES-128-GCM একটি আলোচনা তালিকা, এবং দুটি এন্ট্রিই AEAD, তাই কোনোটি পেলোড সুরক্ষার জন্য auth ডাইজেস্ট ব্যবহার করে না।
কন্ট্রোল-চ্যানেল সুরক্ষাকে আলাদা সিদ্ধান্ত হিসেবে দেখুন
tls-auth কন্ট্রোল-চ্যানেল প্যাকেটে HMAC যোগ করে এবং তার ডাইজেস্ট auth সেটিং থেকে নেয়, তাই একটি AEAD টানেলেও অর্থপূর্ণ ডাইজেস্ট কনফিগার থাকতে পারে। tls-crypt নিজস্ব নির্দিষ্ট সুরক্ষাসহ ভিন্ন বিন্যাস, তাই এটা ধরে নেবেন না যে এটি tls-auth-এর প্রতিটি বৈশিষ্ট্য উত্তরাধিকারে পায়। অনুমান এক থেকে আরেকটিতে স্থানান্তরের বদলে আপনি যে মেকানিজম বেছে নিয়েছেন তার ডকুমেন্টেশন পড়ুন।
দুই পিয়ারকে বিন্যাস এবং কী-এর দিক নিয়েও একমত হতে হবে। মিলে যাওয়া ডাইজেস্ট কিন্তু ভুল দিকে ব্যবহৃত কী ফাইল এমন হ্যান্ডশেক তৈরি করে যা ডাইজেস্ট সেটিং ব্যাখ্যা করতে পারে না এমন কারণে ব্যর্থ হয়।
auth-কে সাইফার আলোচনা ও সার্টিফিকেট থেকে আলাদা রাখুন
তিনটি সেটিং বারবার মিশে যায়: auth ডাইজেস্ট, ডেটা-সাইফার তালিকা এবং সার্টিফিকেটের সিগনেচার অ্যালগরিদম। প্রথমটি বদলালে সার্টিফিকেট পুনরায় ইস্যু হয় না, তার সাইনিং ডাইজেস্ট নির্বাচন হয় না, এবং ইউজার-পাসওয়ার্ড পদ্ধতি তৈরি হয় না। প্রোটোকল অপশন সংজ্ঞাগুলি OpenVPN 2.6 সূত্রে প্রতিটিকে তার নিজস্ব বিভাগে বর্ণনা করে, যা একটি সহায়ক স্মারক যে এগুলি স্বাধীন নব।
ডাইজেস্ট পরিবর্তনের পর কোনো পিয়ার সংযোগ করতে অস্বীকার করলে কারণ সাধারণত অন্য দুটি সেটিংয়ের একটিতে অমিল। যেকোনোটি পরিবর্তনের আগে দুই প্রান্ত পড়ুন।
নীতিটি লিখে রাখুন এবং চলমান কনফিগের সাথে তুলনা করুন
ফ্লিট-স্তরের বিবৃতিতে অনুমোদিত ডেটা-চ্যানেল মোড এবং নির্বাচিত কন্ট্রোল-চ্যানেল সুরক্ষা একই বাক্যে স্পষ্টভাবে উল্লেখ করা উচিত। সেই বাক্যটি পরীক্ষাযোগ্য; “আমরা SHA256 ব্যবহার করি” নয়। তারপর এটিকে সক্রিয় সার্ভার ও ক্লায়েন্ট প্রোফাইলের সাথে তুলনা করুন, কোনো রিপোজিটরির টেমপ্লেটের সাথে নয়।
প্রতিটি টানেল আসলে কী আলোচনা করেছে এবং কোন মেকানিজম তার প্যাকেট প্রমাণায়ন করেছে তা লিপিবদ্ধ করে শেষ করুন। প্রোফাইলে দৃশ্যমান auth লাইন কেবল কনফিগারেশনের অভিপ্রায়ের প্রমাণ, এবং অভিপ্রায় যাচাইয়ের সবচেয়ে সস্তা অংশ।