OpenVPN TLS সাইফার ত্রুটি: আগে দুই পক্ষের তুলনা করুন

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

ক্রমটি ভুল করলে এমন একটি তালিকায় AES নাম যোগ করতে এক ঘণ্টা নষ্ট হতে পারে, যে তালিকা কখনো পড়াই হয়নি।

দুটি সাইফার তালিকা, আর হ্যান্ডশেক ভাঙে কেবল একটি

কন্ট্রোল চ্যানেল একটি TLS সেশন নেগোশিয়েট করে, আর তার পলিসি লেখা হয় tls-cipher দিয়ে TLS 1.2-এর জন্য আর tls-ciphersuites দিয়ে TLS 1.3-এর জন্য। ডেটা চ্যানেল আলাদাভাবে কনফিগার হয় data-ciphers দিয়ে, যেখানে অমিল হলে এমন সংযোগ তৈরি হয় যা প্রতিষ্ঠিত হয় কিন্তু পরে ট্রাফিক পার করতে পারে না। দুটিই সাইফারের কথা বলা ত্রুটি দেয়, তাই এদের গুলিয়ে ফেলা হয়। যে হ্যান্ডশেক কখনো সম্পূর্ণ হয় না তা কন্ট্রোল চ্যানেলের দিকে ইশারা করে, আর যে প্রতিষ্ঠিত টানেল প্যাকেট ফেলে দেয় তা ডেটা চ্যানেলের দিকে।

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

স্যুট তুলনার আগে ভার্সন তুলনা করুন

TLS 1.2-এ সীমিত পক্ষ আর 1.3 আবশ্যক করে এমন পক্ষ কোনো ভার্সন ভাগ করে না, আর কোনো সাইফার স্ট্রিং তা সেতু করতে পারে না। দুই পক্ষেই tls-version-min আর tls-version-max লিখে রাখুন, অথবা ব্যবহৃত বিল্ডগুলোর ডিফল্ট, কারণ কোনো ডিস্ট্রিবিউশনের OpenSSL পলিসি কোনো OpenVPN অপশন না বলেই ন্যূনতম সীমা বাড়িয়ে দিতে পারে। এক পক্ষ যদি অ্যাপ্লায়েন্স বা থার্ড-পার্টি ক্লায়েন্ট হয়, তার উইন্ডো হলো তার ফার্মওয়্যার যা অনুমোদন করে। উইন্ডোগুলো ওভারল্যাপ করার পরেই স্যুট তুলনার কোনো অর্থ হয়।

ওই রেকর্ডগুলোতে প্রকৃত বাইনারিগুলোর নামও থাকা উচিত। কমান্ডলাইন openvpn আপনার ল্যাপটপে জরুরি ভাবে আমদানি করা প্রোফাইল সামলানো ক্লায়েন্ট নয়।

TLS 1.2 আর TLS 1.3 তালিকা মেশে না

TLS 1.2 স্যুটের নামগুলো দেখতে ECDHE-RSA-AES256-GCM-SHA384 এর মতো আর সেগুলো tls-cipher-এ থাকে, যা একটি OpenSSL সাইফার স্ট্রিং নেয়। TLS 1.3 স্যুটের নাম TLS_AES_256_GCM_SHA384 এর মতো আর সেগুলো tls-ciphersuites-এ থাকে; 1.2 স্ট্রিংয়ে একটি যোগ করলে 1.3 তালিকা কনফিগার হয় না, আর পার্সার লেখাটি কখনো মিলিয়ে না দেখেই গ্রহণ করতে পারে। এক ভার্সনের জন্য সঠিক ফিল্টার অন্য ভার্সন সম্পর্কে কিছুই বলে না। কোন তালিকা কোন ভার্সনের জন্য লেখা তা লিখে রাখুন।

openvpn --show-tls লোকাল বিল্ড কী সমর্থন করে তা ছাপে, আর সেটি একটি তালিকা, প্রতিশ্রুতি নয়: দূরের পক্ষ ওই স্যুটগুলো অনুমোদন না-ও করতে পারে, আর সক্রিয় প্রোফাইল সেগুলো চালু না-ও করতে পারে। এটি ব্যবহার করুন এমন বিল্ড বাদ দিতে যা আদৌ কোনো স্যুট দিতে পারে না, তারপর কনফিগার করা তালিকাগুলো তুলনা করুন।

নতুন সংযোগে নেগোশিয়েশন প্রমাণ করুন

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

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

পরিবর্তনের টিকিটে নেগোশিয়েট হওয়া ভার্সন, স্যুট ও ডেটা সাইফার লিখে রাখুন। পরবর্তী যে ব্যক্তি TLS ত্রুটির মুখোমুখি হবেন তিনি ফোরাম পোস্টে পাওয়া সাইফার স্ট্রিং থেকে নয়, সেই রেকর্ড থেকেই শুরু করবেন।