tls-auth key-direction: 0 ও 1 অবশ্যই আলাদা হতে হবে, মিলবে না
tls-auth-এ দুই প্রান্তের বিপরীত দিক লাগে, 0 ও 1, নয়তো দুটোই সেটিংটি বাদ দিতে হবে। একই সংখ্যা ব্যর্থ হয়, আর tls-crypt এটি কখনো ব্যবহার করে না।
টানেলের এক প্রান্ত নিয়ন্ত্রণ চ্যানেলটি এমন একটি কী স্লট দিয়ে সাইন করে যা অন্য প্রান্ত কখনো যাচাই করে না, ফলে একটি সার্টিফিকেট বিনিময়ের আগেই সংযোগটি প্রমাণীকরণ ত্রুটিতে মারা যায়। tls-auth-এর দিক অমিল এমনই দেখায়, এবং এটি নির্ধারক: একই দুটি ফাইল প্রতিটি চেষ্টায়, প্রতিটি নেটওয়ার্ক থেকে ব্যর্থ হয়। লগে আপনি যে অপশনটি খুঁজছেন তার নাম নেই, তাই মানুষ কখনো না-ভাঙা কী নতুন করে বানায় আর সার্টিফিকেট পুনরায় ইস্যু করে। সমাধান হলো দুই প্রান্তকে পরিপূরক করা, বা দুটোকেই দ্বিমুখী রাখা, যাচাই দুর্বল করা নয়।
ব্যর্থতা সার্টিফিকেটের আগেই ঘটে
tls-auth-এ দুই পিয়ার একই শেয়ার্ড কী ধরে রাখে এবং প্রত্যেকে তা থেকে উদ্ভূত দুটি স্লটের একটি ব্যবহার করে: একটি স্লট বহির্গামী নিয়ন্ত্রণ প্যাকেট সাইন করে, অন্যটি আগত প্যাকেট যাচাই করে। দিক 0 ও দিক 1 এই ভূমিকাগুলো উল্টো ক্রমে নির্ধারণ করে, তাই HMAC যাচাই মিলতে দুটি পরিপূরক হতে হবে। এক প্রান্তে বরাদ্দ উল্টে গেলে প্রাপক ভুল স্লটে স্বাক্ষর খোঁজে এবং প্যাকেট প্রত্যাখ্যান করে। সেশন সেখানেই শেষ হয়, তাই ত্রুটিটি প্যাকেট প্রমাণীকরণ নিয়ে, সার্টিফিকেট স্টোর যা তৈরি করত তা নিয়ে নয়।
নির্ধারকতা রোগনির্ণয়ের জন্য গুরুত্বপূর্ণ, কারণ সময় বা পথের সমস্যা ভিন্ন চিহ্ন রেখে যায়: অনিয়মিত বিচ্ছেদ, এক দিকের ব্যর্থতা, বা কেবল নির্দিষ্ট নেটওয়ার্কে মারা যাওয়া সেশন। দিক অমিল প্রতিবার প্রথম হ্যান্ডশেকেই ব্যর্থ হয়, আর একই দুটি ফাইল ধরা অন্য মেশিনেও একইভাবে ব্যর্থ হয়। --verb 4-এ লগ পড়ুন এবং শেষ লাইনের বদলে প্রথম প্রত্যাখ্যাত প্যাকেট খুঁজুন। যদি সেই প্রত্যাখ্যান কোনো সার্টিফিকেট বিনিময়ের আগে ঘটে, তবে শেয়ার্ড কী ও তার দিকই পরীক্ষার যোগ্য দুটি জিনিস।
| What you see | What it rules out | Next check |
|---|---|---|
| Authentication error before any certificate is sent | The data channel is irrelevant; the control channel never authenticated | Compare tls-auth and its direction on both ends |
| Certificate or handshake failure after the control channel authenticates | The shared key and its direction already agree | Check the CA, the certificate dates and the hostname |
| Session completes but throughput or cipher warnings appear | Direction was never the problem | Compare the data-channel cipher settings |
| Startup stops on an options error | The number itself is not the issue | Re-read the inline versus external directive syntax |
সংখ্যাটি কোথায় থাকে
OpenVPN 2.6 ম্যানুয়াল দিকের জন্য দুটি জায়গার কথা বলে: কী আলাদা ফাইলে থাকলে tls-auth-এর দ্বিতীয় আর্গুমেন্ট, আর কী প্রোফাইলে ইনলাইন থাকলে আলাদা key-direction লাইন। দুটোই একই মান সেট করে, তাই প্রোফাইলে একটিই রূপ ব্যবহার করা উচিত, দুটোই কখনো নয়। বাদ দেওয়াও একটি পছন্দ, এবং এটি দুই পিয়ারকে দ্বিমুখী বিন্যাসে রাখে যা কাজ করে যখন কোনো পক্ষই দিক উল্লেখ করে না। একই সংখ্যা বহনকারী দুই পিয়ার সেই বিন্যাসে নেই: প্রত্যেকে এক স্লটে সাইন ও অন্যটিতে যাচাইয়ের আশা করে, আর দুজনেই তা একই দিকে করে।
# server.conf, external key tls-auth ta.key 0 # client.ovpn, external key tls-auth ta.key 1 # client.ovpn, inline key key-direction 1
ইনলাইন রূপটি নিজস্ব লাইনে একটি নির্দেশ, কী ব্লকের খোলা ট্যাগে অ্যাট্রিবিউট নয়, এবং সেই ট্যাগে আর্গুমেন্ট যোগ করা দিক পরিবর্তন নয়, ত্রুটি। অবস্থানও গুরুত্বপূর্ণ: নির্দেশটি যে ব্লকের অন্তর্গত তার বাইরে থাকে, তাই ব্লকের ভিতরে লেখা মান কী উপাদান হিসেবে পড়া হয়। প্রোফাইলের পরিবেশক যে বিন্যাস চেয়েছিলেন তা কপি করুন, জোড়া বানিয়ে নয়, কারণ এক সার্ভারের বিপরীতে কাজ করা প্রোফাইল হয়তো অন্য প্রান্তে ইতিমধ্যে আয়নাকৃত।
অপশনটি যা অপরিবর্তিত রাখে
এটি অ্যাপ্লিকেশন ট্রাফিক এনক্রিপ্ট করে না। tls-auth নিয়ন্ত্রণ চ্যানেলের প্যাকেটের চারপাশে HMAC বসায়, আর ডেটা চ্যানেল হ্যান্ডশেকের সময় সমঝোতা করা সেশন কী দিয়ে সুরক্ষিত, তাই থ্রুপুট বা সাইফারের প্রশ্নের সঙ্গে দিকের সংখ্যার কোনো সম্পর্ক নেই। সেটিংটি দ্বিতীয় এনক্রিপশন স্তরও যোগ করে না, আর এই ধারণাটিই মানুষকে দীর্ঘতর কী খুঁজতে পাঠায়।
এটি tls-crypt-এ প্রযোজ্য নয়, নিজস্ব অপশন ও কী ব্যবস্থাপনাসহ ভিন্ন একটি নিয়ন্ত্রণ চ্যানেল প্রক্রিয়া, এবং এটি কোনো পক্ষের সার্টিফিকেট পরিচয় সম্পর্কে কিছু বলে না। তাই কার্যকর দিক মিল কেবল প্রমাণ করে দুই প্রান্ত নিয়ন্ত্রণ চ্যানেল কীভাবে প্রমাণীকরণ করবে তা নিয়ে একমত, বিশ্বাস-শৃঙ্খল যাচাই হয়েছে তা নয়।
জোড়াটি মিলিয়ে আবার সংযোগ করুন
যেকোনোটি বদলানোর আগে দুটি কনফিগারেশন তুলনা করুন, কারণ যে প্রান্ত ইতিমধ্যে সঠিক ছিল তা সম্পাদনা করলে কাজ দ্বিগুণ হয়। নিচের grep দেখায় প্রতিটি ফাইল কোন প্রক্রিয়া বেছে নেয়; বিস্তারিত রান দেখায় নিয়ন্ত্রণ চ্যানেল আদৌ প্রমাণীকৃত হয়েছে কি না। দুটি আউটপুটই রাখুন, যাতে পরের পরিবর্তনটি পরিচিত অবস্থার সঙ্গে তুলনা করা যায়।
grep -n -E 'tls-auth|tls-crypt|key-direction' server.conf client.ovpn openvpn --config client.ovpn --verb 4 2>&1 | grep -i -E 'hmac|tls error|control channel'
যেকোনো পরিবর্তনের পরে দুই পিয়ার পুনরায় চালু করুন, কারণ এই অপশনগুলো শুরুতে একবার পড়া হয় এবং এক প্রান্ত পুনরায় লোড করলে পুরনো সেশনের জীবদ্দশায় জোড়াটি অসামঞ্জস্যপূর্ণ থাকে। বর্তমানে যদি কোনো দিক কনফিগার না করেই স্থাপনা কাজ করে, তবে এক প্রান্তে সেটিং যোগ করলে আপনি যে ব্যর্থতা দিয়ে শুরু করেছিলেন তা পুনরুৎপাদন হবে; হয় দুটোই ছেড়ে দিন, নয় দুটোই কনফিগার করুন। একবারে এক প্রান্ত বদলান ও আগের ফাইল রাখুন, যাতে রিগ্রেশন পুনর্নির্মাণ নয়, দুই মিনিটের প্রত্যাবর্তন হয়।
প্রতিটি প্রান্তের প্রক্রিয়া, কী ফাইল ও দিক স্থাপনার নোটে লিখে রাখুন, নইলে পরের ব্যক্তি দুটি অনুরূপ ফাইল পড়ে ধরে নেবে সংখ্যাগুলো একে অপরের সঙ্গে মিলতে হবে। দিকটি সমন্বয়ের খুঁটিনাটি, নিরাপত্তা উন্নয়ন নয়: এটি নিয়ন্ত্রণ চ্যানেলের দুই দিক আলাদা করে এবং আর কিছু করে না।