কেন opt-verify যোগ করলে OpenVPN সাইফার ত্রুটি ঠিক হবে না
বিকল্পটি option-string সামঞ্জস্য যাচাই করত এবং 2.7-এ সরিয়ে ফেলা হয়েছে। যে প্রোফাইল এখনও পার্স হয়, তা সাইফার, TLS বা সার্টিফিকেট স্তর সম্পর্কে কিছুই প্রমাণ করে না।
আপনি opt-verify যোগ করার পরামর্শ পান, লাইনটি যোগ করেন, আর সাইফার ত্রুটি ঠিক যেখানে ছিল সেখানেই থাকে। এই ফলাফল অনুমেয়, কারণ বিকল্পটি কখনও সাইফার নিয়ে দর-কষাকষি করেনি। এটি ছিল option-সামঞ্জস্য যাচাই, যা 2.6-এ বাতিল এবং 2.7-এ সরানো হয়েছে, আর এটি দিয়ে যে প্রোফাইল এখনও পার্স হয়, তা এর মাধ্যমে কিছুই প্রয়োগ করেনি।
লাইনটি আগে কী করত তা জানা সহায়ক, তারপর সিদ্ধান্ত নেওয়া যে এটিই অনুপস্থিত অংশ। ইতিহাসটি এও ব্যাখ্যা করে কেন এটি এখন সাহায্য করতে পারে না।
বিকল্পটি আগে কী প্রয়োগ করত
2.6 ম্যানুয়াল opt-verify কে বাতিল হিসেবে চিহ্নিত করে এবং আগের আচরণ বর্ণনা করে: সার্ভার এমন ক্লায়েন্টদের বাদ দেয় যাদের ঘোষিত বিকল্প তার নিজের সাথে মেলে না, ডিভাইসের ধরন ও MTU-এর মতো জিনিস তুলনা করে। ওই যাচাই নির্ভর করে option-সামঞ্জস্য যাচাই চালু থাকার উপরও, তাই disable-occ দিয়ে চলা সার্ভারে এটি শুরুতেই ছিল না। খেয়াল করুন তুলনাটি কী দিয়ে গড়া: সমকক্ষের কনফিগারেশন বর্ণনা করা টেক্সট। ডেটা চ্যানেল কোন সাইফার ব্যবহার করবে তা নিয়ে এটি কিছুই বলে না।
এটিই প্রথম কারণ যে ফ্ল্যাগটি সাইফার ত্রুটি মেরামত করতে পারে না। সাইফার নির্বাচন data-ciphers নীতি এবং উভয় পক্ষ কী সমর্থন করে তা দ্বারা নিয়ন্ত্রিত, আর একটি টেক্সটগত সামঞ্জস্য যাচাই সেই তালিকা বাড়ায় না, দর-কষাকষিও করে না। দ্বিতীয় কারণটি পরিধি: যাচাইটি ঘোষিত বিকল্পগুলো সামঞ্জস্যপূর্ণ দেখায় কি না তা নিয়ে, ফলে যে পথ তৈরি হয় তার গুণমান নিয়ে নয়।
2.7 লাইনটি দেখলে কী করে
2.7-এ বিকল্পটি আর নেই। পার্সার এখনও নামটি চিনতে পারে, তাই একটি পুরোনো প্রোফাইল সিনট্যাক্স ত্রুটি ছাড়াই লোড হয়, এবং এটি জানায় যে বিকল্পটি সরানো হয়েছে, নীরবে পাশ কাটিয়ে যায় না। নাম চেনা আর আচরণ প্রয়োগ করা ভিন্ন জিনিস, এবং এখনও কেবল প্রথমটিই ঘটে। সরানোর নোটগুলি কারণ দেয়: একবার প্যারামিটার নিয়ে দর-কষাকষি করা গেলে, দুই পক্ষ সংযোগ নিয়ে একমত হয়েও বৈধভাবে ভিন্ন বিকল্প স্ট্রিং রাখতে পারে।
তাই যে প্রোফাইল পার্স হয়, তা কোনো ভর্তি-যাচাই চলেছে তার প্রমাণ নয়। যদি আপনার একমাত্র সংকেত হয় যে ক্লায়েন্ট সংযুক্ত হয়েছে, তবে আপনি জেনেছেন যে সিনট্যাক্সটি গৃহীত হয়েছে।
ব্যর্থতা আসলে কোথায় থাকে
কিছু বদলানোর আগে প্রথম সুনির্দিষ্ট ত্রুটিটি সংরক্ষণ করুন, কারণ পরের বার্তাগুলো সাধারণত তার পরিণতি। ডেটা-চ্যানেল দর-কষাকষির ব্যর্থতা অনুমোদিত সাইফার নীতি এবং উভয় পক্ষ যে সক্ষমতা সত্যিই ঘোষণা করে তার সাথে সম্পর্কিত। TLS সংস্করণ বা স্যুট ব্যর্থতা নিয়ন্ত্রণ চ্যানেলের সাথে সম্পর্কিত। সার্টিফিকেট প্রত্যাখ্যানের জন্য প্রয়োজন পরিচয় ও বিশ্বাস-শৃঙ্খল, সামঞ্জস্যের ফ্ল্যাগ নয়।
উভয় প্রান্তের ইঞ্জিনও চিহ্নিত করুন। একটি ডেস্কটপ অ্যাপ্লিকেশন আপনার পরীক্ষা করা কমান্ড-লাইন বাইনারি থেকে ভিন্ন বিল্ড বান্ডল করতে পারে, আর বিকল্প সমর্থন তাদের মধ্যে ভিন্ন। প্রতিটি প্রোগ্রাম যা প্রোফাইল আমদানি করে একইভাবে আচরণ করে ধরে নেওয়ার বদলে সেই ইঞ্জিনের ডকুমেন্টেশন দেখুন।
শুধু লাইন নয়, উদ্দেশ্যটি প্রতিস্থাপন করুন
যদি কোনো পুরোনো পরিচালিত সার্ভার সত্যিই সামঞ্জস্য যাচাইয়ের উপর নির্ভর করত, তবে আপগ্রেডের আগে এটি কোন সীমাবদ্ধতা প্রয়োগ করত তা লিখে রাখুন। নতুন প্রোফাইলে একটি উপেক্ষিত বিকল্প রাখা সেই নীতি সংরক্ষণ করতে পারে না, আর এলোমেলোভাবে লাইন মুছে ফেলেও তা করা যায় না।
সব সাইফার নিষ্ক্রিয় — এমন একটি পুরোনো পরামর্শের জবাবে প্রতিটি ঐতিহাসিক অ্যালগরিদম সক্রিয় করবেন না।
অনুমোদিত সংশোধনের পর, একটি নতুন সংযোগে দর-কষাকষিকৃত ফলাফল পরিদর্শন করুন এবং ব্যবহারকারীর সত্যিই যে অ্যাপ্লিকেশন দরকার তা পরীক্ষা করুন। সার্ভার সংস্করণ ও কার্যকর নীতি সেই ফলাফলের পাশে রাখুন, যাতে পরের ব্যক্তি কেবল গৃহীত নয়, সম্মত হয়েছে তা দেখতে পারেন।
লক্ষ্য হলো একটি সমর্থিত সীমাবদ্ধতা এবং একটি কাজ করা প্রমাণিত পথ, এমন একটি পুরোনো ফ্ল্যাগ নয় যা এখনও পার্স হয়।