OpenVPN tls-ciphersuites বনাম tls-version-min: কোনটি কী প্রয়োগ করে

TLS 1.3 স্যুট তালিকা প্রোটোকল সংস্করণকে সীমাবদ্ধ করে না, আর show-tls কেবল স্থানীয় সমর্থন দেখায়। নীতি, স্যুট ও সমঝোতাকৃত ফলাফল আলাদাভাবে যাচাই করুন।

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

যেকোনো তালিকা পড়ার আগে বিল্ডটি যাচাই করুন

একটি কনফিগারেশন নির্দেশ এমন বাইনারিতে প্রোটোকল সমর্থন যোগ করতে পারে না যেখানে তা নেই। সংস্করণ ব্যানার দিয়ে শুরু করুন, যা কম্পাইল করা ক্রিপ্টো লাইব্রেরির নাম দেয়:

openvpn --version

OpenSSL-এর সঙ্গে লিংক করা 2.6 বিল্ড tls-cipher এবং tls-ciphersuites উভয়ই গ্রহণ করে। mbed TLS-এর সঙ্গে বিল্ডে TLS 1.3 স্যুট নির্বাচনই নেই, আর 2.6 ম্যানুয়াল tls-ciphersuites-কে OpenSSL অপশন হিসেবে চিহ্নিত করে। সার্ভার যদি ভিন্ন ব্যাকএন্ড দিয়ে পুনর্নির্মিত হয়, একই প্রোফাইল কনফিগারেশনের একটি লাইনও না বদলেই আচরণ বদলাতে পারে।

এখানে থাকতেই openvpn --show-tls চালান এবং আউটপুট রেখে দিন। এটিই সেই ইনভেন্টরি যা পরে মিলিয়ে দেখবেন, আর কেউ প্রোফাইল সম্পাদনা শুরু করার আগে এটি ধরে রাখা সস্তা।

ব্যানার ও তালিকাটি চ্যাট উইন্ডোতে নয়, পরিবর্তন টিকিটে লিখুন। ছয় সপ্তাহ পরে কোনো ক্লায়েন্ট একটি স্যুট দিতে পারবে কি না নিয়ে দুইজন বিতর্ক করলে, ধরা পড়া আউটপুট এক লাইনেই বিষয়টি মিটিয়ে দেয়।

সংস্করণ সীমা সাইফার তালিকা থেকে আলাদা রাখুন

2.6 ম্যানুয়ালে এগুলো এক নয়, তিনটি নিয়ন্ত্রণ:

  • tls-cipher TLS 1.2 ও তার আগের সংস্করণের জন্য সাইফার নীতি নির্ধারণ করে এবং OpenSSL-এর সাইফার তালিকায় পাঠানো হয়;
  • tls-ciphersuites TLS 1.3 স্যুট নির্বাচন করে;
  • tls-version-min ও tls-version-max সংযোগটি যে প্রোটোকল সংস্করণ ব্যবহার করতে পারে তার সীমা বেঁধে দেয়।

তাই সযত্নে ছাঁটা TLS 1.3 স্যুট তালিকা পুরোনো সংস্করণ এখনো অনুমোদিত থাকার বিষয়ে কিছুই প্রমাণ করে না। যদি প্রয়োজন হয় «শুধু TLS 1.3», তবে তা বহন করে সংস্করণের নিম্নসীমা, আর স্যুট তালিকা কেবল সেই সীমার ভেতরে বিকল্প সংকুচিত করে:

tls-version-min 1.3
tls-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

এই জোড়া দুটি কাজ করে। একটি লাইন মুছে দিলে অন্যটি আপনি যা ভাবেন তার চেয়ে কম প্রয়োগ করে, আর এই পুরো পরীক্ষাটি ঠিক সেই ব্যর্থতাই ধরার জন্য আছে।

ডেটা চ্যানেল চতুর্থ নিয়ন্ত্রণ। data-ciphers টানেলের ভেতরের প্রতিসম সাইফার নিয়ে সমঝোতা করে, আর তার ফলাফল নিয়ন্ত্রণ চ্যানেলের TLS সংস্করণ সম্পর্কে কিছুই বলে না। সেশন সারাংশে AES-256-GCM দেখা কোনো দিক থেকেই TLS 1.3-এর প্রমাণ নয়।

show-tls-কে স্থানীয় ইনভেন্টরি হিসেবে পড়ুন

--show-tls এই বাইনারি যে ক্রিপ্টো লাইব্রেরির সঙ্গে লিংক করা তার সমর্থিত স্যুটগুলো অগ্রাধিকার ক্রমে তালিকা করে। এটি গেটওয়ে থেকে পাওয়া প্রতিবেদন নয়। ম্যানুয়াল স্পষ্ট করে বলে তালিকাটি স্থানীয় লাইব্রেরি থেকে আসে, অর্থাৎ OpenSSL 3.x-সহ একটি ল্যাপটপ ও পুরোনো বিল্ডের একটি রাউটার একই সার্ভারের সঙ্গে কথা বলেও ভিন্ন তালিকা ছাপবে।

EvidenceWhat it actually describes
--show-tls outputCapabilities of this client build and its library
Profile directivesWhat this attempt is allowed to offer
Session log lineWhat this one negotiation selected

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

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

গেটওয়েকে এমন প্রশ্ন করুন যার উত্তর সে দিতে পারে

আপনি যদি সেবাটি পরিচালনা করেন, ডিস্কের ফাইলের বদলে চলমান ইনস্ট্যান্সের কার্যকর কনফিগারেশন দেখুন। OpenVPN ভিন্ন --config পথে চালু হয়ে থাকতে পারে, ইনক্লুড টানতে পারে, কিংবা সম্পাদনার পর পুনরায় চালু না হয়ে থাকতে পারে। চলমান ডেমনটির নীতি হলো যা ক্লায়েন্টরা পায়।

আপনি যদি এটি পরিচালনা না করেন, অপারেটরের কাছে সমর্থিত ক্লায়েন্ট চাহিদা বা সীমিত গ্রহণযোগ্যতা পরীক্ষা চান। প্রত্যাখ্যাত প্রচেষ্টা মানেই প্রত্যাখ্যাত স্যুট নয়: সংস্করণের নিম্নসীমা, remote-cert-tls-এর মতো সার্টিফিকেট পরিচয় যাচাই, অথবা tls-auth ও tls-crypt-এর মধ্যে অসঙ্গতি স্যুট নির্বাচন গুরুত্বপূর্ণ হওয়ার আগেই বিনিময় শেষ করতে পারে। ক্লায়েন্টের তালিকা বদলানোর আগে সার্ভারের ত্রুটি পড়ুন, কারণ «handshake failed» চারটি ভিন্ন কারণ ঢেকে রাখে এবং তার একটিই সাইফার অসঙ্গতি।

VPN পোর্টে openssl s_client তাক করলেও প্রশ্নটির পুনরুৎপাদন হয় না। নিয়ন্ত্রণ চ্যানেল OpenVPN-এর নিজস্ব ফ্রেমিংয়ের ভেতরে চলে, তাই কাঁচা TLS প্রোব এমন পোর্টে ভিন্ন প্রোটোকল পরীক্ষা করে যা অন্য কিছু প্রত্যাশা করে। এটি থেকে টানা যেকোনো সিদ্ধান্ত প্রোব সম্পর্কে, টানেল সম্পর্কে নয়।

দুটি ফলাফল লিখুন এবং আলাদা রাখুন

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

openvpn --config office.ovpn --verb 4 2>&1 | tee session.txt

তারপর দুটি লাইন স্মৃতি থেকে নয়, ওই ফাইল থেকেই পড়ুন। জোড়াটিই প্রমাণ; কেবল একটি স্যুট নাম একটি পছন্দ, আর সংস্করণ সীমা সার্ভার কী প্রত্যাখ্যান করে সে সম্পর্কে আলাদা বিবৃতি।

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

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

সম্পর্কিত নিবন্ধ