এই OpenVPN নিরাপত্তা সংশোধনটি কি আদৌ আপনার ইনস্টলের বিষয়ে?
প্যাচ করা আর কনফিগার করা ভিন্ন দাবি। এক্সিকিউটেবলটি, তার পেছনের প্যাকেজটি এবং প্রোফাইলটি সত্যিই যে যাচাইগুলো করে তা চিহ্নিত করুন।
সার্টিফিকেট যাচাই করার জন্য ক্লায়েন্টকে প্যাচ করার পরামর্শ কাজ করার পক্ষে খুবই অস্পষ্ট। এটি একটি ঠিক করা সফটওয়্যার ত্রুটি, একজন প্রোভাইডারের পুরোনো বিল্ড, অথবা এমন একটি প্রোফাইল বোঝাতে পারে যা কখনো এই যাচাই চায়নি। এগুলো তিনটি ভিন্ন পরিবর্তন, তিনজন ভিন্ন মালিকের। কোনটির মুখোমুখি হয়েছেন না জেনে এই বাক্য অনুযায়ী কাজ করা মানে একটি কাজ করা ক্লায়েন্টকে কারণ ছাড়াই বদলে ফেলা।
তিনটি দাবি আলাদা করুন
একটি সফটওয়্যার ত্রুটির একটি অ্যাডভাইজরি, আক্রান্ত সংস্করণ এবং একটি ঠিক করা রিলিজ থাকে। একটি প্রোভাইডার বিল্ডের নিজস্ব বিতরণ চ্যানেল ও নিজস্ব আপডেট গতি থাকে। প্রোফাইলের বাদ পড়ার ক্ষেত্রে কোনোটিই নেই, কারণ এক্সিকিউটেবল ঠিক আছে এবং কনফিগারেশন আপনি যা ধরে নিয়েছিলেন তার চেয়ে কম চায়। দাবিটি এই তিনটির একটি না বলা পর্যন্ত পরীক্ষা করার কিছু নেই।
খোঁজার আগে দাবিটি এক বাক্যে লিখুন। বাক্যটি যদি কী ভাঙা তা বলতে না পারে, তবে খোঁজার কোনো লক্ষ্য নেই এবং প্রতিটি ফলাফল প্রাসঙ্গিক মনে হয়।
| Claim | Evidence that settles it | Who owns the change |
|---|---|---|
| Software defect | Advisory naming affected versions | Package or product maintainer |
| Provider build | Release notes for that client | The provider |
| Profile omission | The configuration actually loaded | Whoever owns the profile |
যে এক্সিকিউটেবলটি সত্যিই চলে সেটি খুঁজুন
কোনো সংস্করণ দেখার আগে কী সংযোগটি শুরু করে তা চিহ্নিত করুন। একটি বিতরণ সেবা, একটি ডেস্কটপ প্লাগইন এবং একটি ভেন্ডর অ্যাপ্লিকেশন প্রত্যেকে ভিন্ন এক্সিকিউটেবল বা ইঞ্জিন ব্যবহার করতে পারে। শেলের সার্চ পাথে থাকা যে কোনো বাইনারি যে সংস্করণ ছাপে সেটি মেশিনের কোনো তালিকা নয়। যে ইউনিট বা প্রসেস সত্যিই সংযোগটি করেছে তা পড়ুন।
systemctl cat openvpn-client@*.service
ps -o pid,cmd -C openvpn
apt-cache policy openvpn network-manager-openvpnপ্যাকেজ কোয়েরি জানায় স্থানীয় মেটাডেটা কী ইনস্টল ও উপলব্ধ মনে করে, আর সেই ক্যাশ পুরোনো হতে পারে, তাই আগে তা রিফ্রেশ করুন। এটি এটাও বলে না যে চলমান সেবাটি পাঁচ মিনিট আগে ইনস্টল করা কোনো বাইনারি লোড করেছে কিনা। প্যাকেজ রেকর্ডটিকে সত্যিই সংযুক্ত প্রসেসের সঙ্গে তুলনা করুন।
সংস্করণের ধারণার বদলে প্যাকেজের প্রমাণ
বিতরণের নিরাপত্তা রক্ষণাবেক্ষণ প্রায়ই ঠিকগুলো পিছনে বহন করে, তাই পুরোনো দেখতে একটি আপস্ট্রিম সংস্করণেও প্যাচ থাকতে পারে। উল্টোটাও সত্য: অপরিচিত রিপোজিটরি থেকে আসা প্যাকেজের বর্তমান রক্ষণাবেক্ষণের কোনো স্বয়ংক্রিয় দাবি নেই। সংস্করণ সংখ্যার বদলে রিলিজের সমর্থন অবস্থা পড়ুন।
এই পার্থক্যই আসল ফাঁক আর শুধু পুরোনো দেখতে একটি সংখ্যার মধ্যে পার্থক্য। প্যাকেজটি যে রিপোজিটরি থেকে এসেছে তা লিখে রাখুন, কারণ একই সংস্করণ স্ট্রিং খুব ভিন্ন চ্যানেলে খুব ভিন্ন সমর্থন নিয়ে আসতে পারে।
কনফিগারেশনই অন্য অর্ধেক
রক্ষণাবেক্ষণ করা একটি এক্সিকিউটেবলের তবুও এমন একটি প্রোফাইল দরকার যা আপনি যে যাচাইগুলো চালু মনে করছেন সেগুলো চায়। ট্রাস্ট অ্যাঙ্কর, পিয়ারের অভিপ্রেত ভূমিকা এবং প্রত্যাশিত সার্ভার নাম সম্পর্কিত কিন্তু আলাদা সিদ্ধান্ত। ভূমিকা যাচাই নাম যাচাই নয়, এবং কোনোটিই অন্যটির বিকল্প নয়। সতর্কতাটি যদি কনফিগারেশন সম্পর্কে হয়, তবে সংশোধন প্রোফাইলের মালিকের।
যাচাই না করা প্রোফাইলের ক্ষতিপূরণে কোনো ইচ্ছেমতো প্যাচ ইনস্টল করবেন না, এবং সত্যিকারের বাস্তবায়ন ত্রুটি মেরামতের জন্য কোনো নির্দেশ যোগ করবেন না। দুই ভুলই অগ্রগতির মতো লাগে, তাই দুটোই ঘটতে থাকে।
রেকর্ডের প্রমাণ দিয়ে সিদ্ধান্ত নিন
সিদ্ধান্ত আপনার প্রতিষ্ঠিত বিষয় থেকে আসে। নথিভুক্ত আক্রান্ত প্যাকেজ তার সমর্থিত আপডেট চায়, অসমর্থিত প্ল্যাটফর্মের মাইগ্রেশন পথ দরকার, আর প্রোভাইডার ক্লায়েন্টের সেই প্রোভাইডারের নির্দেশনা দরকার। অস্পষ্ট নির্দেশের ক্ষেত্রে এসবের কোনোটি প্রযোজ্য হওয়ার আগে একটি অ্যাডভাইজরি ও একটি আক্রান্ত উপাদান দরকার।
সক্রিয় ক্লায়েন্ট, সম্পূর্ণ সংস্করণ, অ্যাডভাইজরি এবং প্রোফাইলের মালিককে একসঙ্গে পরিবর্তনের রেকর্ডে রাখুন। এটি টিউটোরিয়ালের রেফারেন্সের চেয়ে শক্তিশালী, এবং পরের ব্যক্তির সত্যিই এটাই দরকার হবে।