OpenVPN প্যাকেট HMAC প্রমাণীকরণ ব্যর্থ: কোন স্তর?

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

বার্তাটি একটি স্তরের নাম বলে, আর কাজ হলো যেকোনো উপাদান বদলানোর আগে কোন স্তর তা ঠিক করা। প্রার্থীদের পাশাপাশি মিলিয়ে দেখা পার্থক্য দেখার দ্রুততম উপায়।

একই শব্দ ভাগ করা দুটি ব্যর্থতা

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

পার্থক্যটি মেরামত বদলে দেয়। একটিতে চ্যানেল সেটিংস মেলানো দরকার, অন্যটিতে অ্যাকাউন্টের অবস্থা, আর তৃতীয়টিতে এমন প্রোফাইল যা যে লিসেনারে পৌঁছেছে তার সঙ্গে মেলে না।

চলমান প্রক্রিয়াটি আসলে কী লোড করেছে তা মেলান

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

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

কন্ট্রোল চ্যানেলের সঙ্গে ডেটা চ্যানেল মেলান

দুটি প্রক্রিয়া সংযোগের ভিন্ন অংশ প্রমাণীকরণ করে এবং আলাদাভাবে কনফিগার হয়, যেমনটি 2.6 অপশন রেফারেন্স বর্ণনা করে। tls-auth কন্ট্রোল-চ্যানেল প্যাকেটে HMAC যোগ করে এবং একটি দিক আর্গুমেন্ট নেয় যা দুই পিয়ারে বিপরীত হতে হবে, অন্যদিকে tls-crypt কন্ট্রোল চ্যানেলকে বদলে একটি শেয়ার্ড কী দিয়ে সুরক্ষিত করে। কোনোটিই ডেটা চ্যানেলের নিজস্ব অখণ্ডতা যাচাই নয়। AEAD ডেটা সাইফারে সেই যাচাই সাইফারের ভেতরেই থাকে, তাই আলাদা auth ডাইজেস্ট নন-AEAD সাইফারের মতো ব্যবহার হয় না।

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

সমাধানটিকে আপনি যে বৈশিষ্ট্য ছাড় দিচ্ছেন তার সঙ্গে মেলান

প্যাকেট প্রমাণীকরণ বন্ধ করলে সতর্কবার্তা থামে এবং যে যাচাই অমিলটি খুঁজে পেয়েছিল তা সরে যায়, যা প্রোফাইল মেরামতের সমান নয়। জিজ্ঞেস করুন কোন বৈশিষ্ট্য আপনি ছাড়ছেন এবং তা ছাড়া নকশা টেকে কি না।

কিছু বদলানোর আগে দুই প্রান্তে প্রথম প্রাসঙ্গিক ঘটনাটি পড়ুন, তারপর কেবল সেই অমিলটিই বদলান যার নাম তা বলে।

পরের চেষ্টা যদি সার্টিফিকেট বা লগইন ত্রুটি পর্যন্ত এগোয়, তবে তা অগ্রগতি, পশ্চাদপসরণ নয়: প্যাকেট স্তর এখন একমত এবং সংযোগ এগিয়ে গেছে। যে সেটিংস পরিবর্তনটি ঘটিয়েছে তা লিখে রাখুন, যাতে পরের মানুষ রহস্য নয়, ব্যাখ্যা উত্তরাধিকার পায়।