OpenVPN কন্ট্রোল প্যাকেট ট্রেস করা: TLS-এর আগে tls-auth

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

এনভেলপ যেভাবে তৈরি হয় সেই ক্রমেই পড়ুন

একটি কন্ট্রোল প্যাকেটে একটি সেশন শনাক্তকারী, ঐচ্ছিক tls-auth HMAC, রিপ্লে ও স্বীকৃতি তথ্য এবং একটি নির্ভরযোগ্য বার্তা শনাক্তকারী থাকে, তার পরে আসে বার্তা ধরনের পেলোড। বার্তাটি হ্যান্ডশেক বার্তা হলে পেলোডটি TLS সাইফারটেক্সট হয়ে যায়। সম্পর্কটি পুরোটাই এই: TLS উপাদান এমন একটি বার্তার ভিতরে যায় যা এনভেলপ ইতিমধ্যেই সুরক্ষিত করে। দেখুন OpenVPN নেটওয়ার্ক প্রোটোকল রেফারেন্স যা সেই ক্রমেই কন্ট্রোল চ্যানেলের ফিল্ডগুলো তালিকাভুক্ত করে।

নির্ভরযোগ্যতা স্তরকে ক্রিপ্টোগ্রাফি ভেবে ভুল করা সহজ। স্বীকৃতি, পুনঃপ্রেরণ ও বার্তা শনাক্তকারী আছে যাতে অবিশ্বস্ত পরিবহনে কন্ট্রোল বার্তা একবার ও ক্রমে পৌঁছায়। এগুলো প্রমাণীকরণ নয়, আর সঠিক বার্তা শনাক্তকারী প্যাকেট কে পাঠিয়েছে সে বিষয়ে কিছুই প্রমাণ করে না।

এই গ্রুপিংকে ধারণাগত রাখুন। এটি বাইট-ক্রমের চিত্র নয়, এবং একটি ট্যাগ গণনার জন্য যথেষ্ট নয়, কারণ HMAC-এ ঢোকা ফিল্ডগুলো বাস্তবায়ন, সংস্করণ ও মোডের উপর নির্ভর করে।

দেখান যে যাচাই হ্যান্ডশেকের আগেই চলে

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

ডেমনের ভার্বোসিটি বাড়ান এবং tun ডিভাইসের বদলে কন্ট্রোল চ্যানেল লক্ষ্য করুন:

openvpn --config /etc/openvpn/server.conf --verb 6

আপনি খুঁজছেন প্যাকেট স্তরে রিপোর্ট হওয়া কন্ট্রোল-চ্যানেল HMAC যাচাই ব্যর্থতা, কোনো TLS সতর্কতার আগে। লগে TLS সতর্কতা মানে এনভেলপ গৃহীত হয়েছে এবং ব্যর্থতা ভিতরের দিকে সরে গেছে, যা ভিন্ন সমাধানসহ ভিন্ন তদন্ত।

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

দুই প্রান্তে কী, দিক ও digest মিলিয়ে নিন

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

grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf

শেয়ার করা গোপনীয়তা এডিটর দিয়ে নয়, টুল দিয়ে তৈরি করুন এবং অনুমতি সংকীর্ণ রাখুন:

openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key

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

tls-auth-কে tls-crypt-এর সাথে গুলিয়ে ফেলবেন না। দুটোই কন্ট্রোল চ্যানেল সুরক্ষিত করে, কিন্তু tls-crypt এটিকে এনক্রিপ্টও করে এবং পর্যবেক্ষকদের থেকে হ্যান্ডশেক লুকায়, এবং এটি দিক বিভাজনকে নিজস্ব কী পরিচালনা দিয়ে প্রতিস্থাপন করে। একটির প্রোফাইল অন্যটির জন্য কনফিগার করা প্রান্তের সাথে কাজ করবে না, আর digest টিউনিং দিয়ে সেই ফাঁক বন্ধ হয় না।

প্রকৃত ফরম্যাট থেকেই ট্যাগ পুনরুৎপাদন করুন

বাইট-নিখুঁত পুনরুৎপাদন VPN চালানোর থেকে আলাদা কাজ, এবং এটি কেবল প্রকৃত ইনপুট দিয়েই সম্ভব: প্যাকেটটি তৈরি করা বাস্তবায়ন ও সংস্করণ, নির্বাচিত digest, দিক, এবং সেশন শনাক্তকারী ও স্বীকৃতি অ্যারে সহ প্রকৃত বাইট। ফিল্ড তালিকার টেক্সট রূপ সেই বাইট নয়।

ট্যাগের দৈর্ঘ্য digest থেকে আসে, তাই নির্দিষ্ট দৈর্ঘ্যের অনুমান কেউ এটি বদলালেই ভেঙে পড়ে। প্যাকেটটি বাস্তবায়ন যেভাবে করে সেভাবেই হ্যাশ করুন, ব্লগ পোস্টের টেবিল যেভাবে উপস্থাপন করে সেভাবে নয়, এবং হাতে বের করা প্রত্যাশার বদলে একই প্রান্ত থেকে নেওয়া ক্যাপচারের সাথে তুলনা করুন।

এই অনুশীলনটি উৎপাদন প্রোফাইল থেকে দূরে রাখুন। ট্যাগ পুনরুৎপাদনে এমন কিছু নেই যা আপনাকে বলে কোনো স্থাপনায় সুরক্ষা চালু করা উচিত কি না।

সুরক্ষা না সরিয়েই অমিল ফিরিয়ে আনুন

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

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

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