সুবিধা কমানোর পরে: কোন OpenVPN ফাইলগুলি এখনও কাজ করে?
সুবিধা কমানোর আগে খোলা ডেসক্রিপ্টরগুলি কাজ করতে থাকে; পরে আবার খোলা পাথগুলি আর কাজ করে না। আপনার সেটআপে তিনটি রানটাইম ফাইলের কোনটি আবার খুলতে হবে তা নির্ধারণ করুন।
দীর্ঘ আপটাইম শুধু প্রমাণ করে যে ডেমনটি সেই মুহূর্তে যে সুবিধা ধরে রেখেছিল, তা দিয়েই স্টার্টআপ সফল হয়েছিল। এখানে যে ব্যর্থতাগুলি গুরুত্বপূর্ণ সেগুলি পরে আসে: একটি নতুন ক্লায়েন্ট সংযুক্ত হয়, একটি রিভোকেশন তালিকা প্রতিস্থাপিত হয়, একটি হেল্পারকে একটি ফাইল লিখতে হয়। এর প্রত্যেকটি হলো অসুবিধাভোগী অ্যাকাউন্ট দ্বারা করা একটি নতুন ওপেন, নিজস্ব অনুমতি-প্রশ্ন ও নিজস্ব ত্রুটি-বার্তা সহ। তিনটি সিদ্ধান্ত এমন একটি কনফিগারেশনকে আলাদা করে যা কাজ করতে থাকে, এমন একটি থেকে যা পরের ঘটনাতেই ব্যর্থ হয়।
শুরুর দিকে লোড হওয়া জিনিস ও পরে খোলা জিনিস আলাদা করুন
ডেসক্রিপ্টর হলো একটি খোলা ফাইল-বিবরণীর হ্যান্ডেল, আর অ্যাক্সেস মোড সেই বিবরণী তৈরি হওয়ার সময়েই নির্ধারিত হয়ে যায়। পরে প্রসেসের ব্যবহারকারী বদলালে হ্যান্ডেল বন্ধ হয় না, তাই root হিসেবে পড়া একটি কী-ফাইল সুবিধা কমানোর পরেও কাজ করতে থাকে। মোডও বদলায় না: পড়ার জন্য খোলা হ্যান্ডেল লেখার যোগ্য হয়ে ওঠে না, আর অ্যাকাউন্টটি পাথের উপর তার অধিকার হারালেই কোনো লেখার যোগ্য হ্যান্ডেল বাতিল হয় না। এই দুটি তথ্যই এই প্রতিবেদনগুলির বেশিরভাগ বিস্ময়কর আচরণ ব্যাখ্যা করে।
বাকি অর্ধেকটি স্মৃতি। একটি ডেমন একটি সার্টিফিকেট পার্স করে, পার্স করা উপাদান ধরে রাখতে এবং ফাইলটি বন্ধ করতে পারে; ব্যবহৃত অবস্থায় থাকে ডেটা, খোলা ফাইল নয়। তাই চলমান ট্রাফিক প্রমাণ করে না যে কোনো ডেসক্রিপ্টর খোলা আছে বা পাথনামটি পৌঁছানোর মতো। এটি প্রমাণ করে যে বর্তমান সেশনের জন্য প্রয়োজনীয় উপাদান আগেই কোনো এক সময়ে সংগ্রহ করা হয়েছিল।
পরে করা ওপেন একটি ভিন্ন লেনদেন। এটি বর্তমান ক্রেডেনশিয়াল, বর্তমান নিরাপত্তা প্রসঙ্গ ও বর্তমান মাউন্ট-দৃশ্যের অধীনে চলে, তাই বুটের সময় পাঠযোগ্য একটি পাথ পরের সংযোগে প্রত্যাখ্যাত হতে পারে। রোটেশন আরেকটি ফাঁদ যোগ করে: একই পাথনামের উপর নতুন ফাইল লিখলে বিদ্যমান ডেসক্রিপ্টর পুরোনো অবজেক্টের সাথেই যুক্ত থাকে, তাই রিলোড সফল বলে মনে হতে পারে অথচ ডেমন আগের বিষয়বস্তুই ব্যবহার করে। রোটেশন কার্যকর হয়েছে বলে বিশ্বাস করার আগে প্রসেসটি যে আইনোড ধরে আছে তা ডিস্কের আইনোডের সাথে মিলিয়ে দেখুন।
তিনটি রানটাইম রিডের নাম বলুন এবং কোনটি কখন ঘটে
সাধারণত তিনটি রিসোর্স ইনিশিয়ালাইজেশনের অনেক পরে খোলা হয়, আর সেগুলি ভিন্ন ভিন্ন মুহূর্তে ব্যর্থ হয়। ক্লায়েন্ট-নির্দিষ্ট কনফিগারেশন ফাইল সেই নির্দিষ্ট ক্লায়েন্ট সংযুক্ত হওয়ার সময় পড়া হয়, তাই একজন ব্যবহারকারীর জন্য তা ভেঙে যেতে পারে, বাকিরা চলতে থাকে। রিভোকেশন ডেটা পিয়ার অথেন্টিকেশনের সময় এবং ফাইলটি প্রতিস্থাপিত হলে আবার দেখা হয়। কোনো স্ক্রিপ্ট বা প্লাগইন কিছু লিখলেই কেবল একটি অস্থায়ী ডিরেক্টরি স্পর্শ করা হয়।
তিনটির কোনোটিই স্টার্টআপ পাথে পড়ে না, তাই সপ্তাহের পর সপ্তাহ সুস্থ থাকা একটি সার্ভার পরের সংযোগেই ব্যর্থ হতে পারে। এই শ্রেণিবিন্যাস সমাধানের দায়িত্বাধীন জিনিসটিও বলে দেয়: প্রথম দুটি ডেমন অ্যাকাউন্টের অধীনে কনফিগারেশনের পড়ার অনুমতি, আর তৃতীয়টি সংকীর্ণ উদ্দেশ্যের একটি লেখার যোগ্য অবস্থান।
| Path reopened later | What triggers the open | First sign when it fails |
|---|---|---|
| Client configuration file | A connection for that client identity | One client rejected while others connect |
| Revocation data | Peer authentication, including after replacement | Revoked and valid peers both refused |
| Script or plugin temporary directory | A helper needs to create a file | The helper exits with a path error |
persist-key বেশিরভাগ মানুষ যা ভাবেন তার চেয়ে সংকীর্ণ প্রশ্নের উত্তর দেয়। এটি নথিভুক্ত SIGUSR1 ও ping-restart রিসেট জুড়ে কী-ফাইলটি খোলা রাখে, আর CCD ফাইল, রিভোকেশন ডেটা, হেল্পার এক্সিকিউটেবল বা সম্পূর্ণ প্রসেস রিস্টার্টের জন্য কিছুই করে না। সেগুলি তখন যে অ্যাকাউন্ট চলছে তার অধীনেই নিজেদের ওপেন-পাথ অনুসরণ করে।
অ্যাকাউন্টটি এবং সত্যিই তার যে দৃশ্য আছে তা নিশ্চিত করুন
ইউনিট ফাইলকে বিশ্বাস না করে চলমান ডেমনকেই জিজ্ঞাসা করুন সে কোন অ্যাকাউন্ট ব্যবহার করছে, তারপর উত্তরটি ইউনিট যা সেট করে তার সাথে মিলিয়ে দেখুন। অমিলই প্রথমে সমাধান করার জিনিস, কারণ পরের প্রতিটি অনুমতি-যাচাই প্রসেসটি সত্যিই যে তার পরিচয়েই চলে। তারপর পাথটি একবারে একটি উপাদান করে হাঁটুন; প্রতিটি স্তরে ট্রাভার্সাল যাচাই হয়, তাই অপাঠ্য ডিরেক্টরির ভিতরে পাঠযোগ্য ফাইলও অপাঠ্যই থাকে। শেষ ফাইল-মোড হলো শেষ প্রশ্ন, প্রথম নয়।
নেমস্পেস ও সার্ভিস স্যান্ডবক্স এমন সীমানা যোগ করে যা মালিকানা ও মোড-বিট বর্ণনা করে না। আপনার শেলে দৃশ্যমান একটি পাথ chroot, মাউন্ট নেমস্পেস বা হোম ডিরেক্টরি লুকানো একটি ইউনিটের ভিতরে অনুপস্থিত বা কেবল-পাঠযোগ্য হতে পারে। নিরাপত্তা মডিউল আরেকটি স্তর যোগ করে, তাই পাঠযোগ্য দেখতে পাওয়া একটি ফাইল খোলার সময়ও প্রত্যাখ্যাত হতে পারে।
ps -o user:12,pid,args -C openvpn
systemctl show -p User -p Group -p ProtectHome -p RootDirectory [email protected]
sudo -u openvpn namei -l /etc/openvpn/ccd/aliceঅ্যাডমিনিস্ট্রেটরের শেলে সফল পাঠ ওই সম্মিলিত শর্তগুলির কোনোটিই পরীক্ষা করে না। ডেমন অ্যাকাউন্ট হিসেবেই, একই নেমস্পেস ও স্যান্ডবক্স নিয়ে পরীক্ষাটি চালান, নইলে মেনে নিন যে ফলাফলটি সার্ভারের নয়, আপনার শেলের বর্ণনা দেয়। তৃতীয় কমান্ডটি সেই পরীক্ষার সস্তা সংস্করণ: এটি প্রতিটি উপাদানের মোড ছাপায় এবং ডেমন অ্যাকাউন্ট যে প্রথমটিতে ট্রাভার্স করতে পারে না সেখানেই ব্যর্থ হয়।
রানটাইম লেখার অনুমতি তার নিজস্ব ডিরেক্টরিতে দিন
পড়া হলো তালিকার কেবল অর্ধেক। একটি হেল্পার স্ক্রিপ্টকে স্টেটাস ফাইল তৈরি করতে হতে পারে, একটি প্লাগইনকে তার কনফিগারেশনের পাশে স্টেট লিখতে হতে পারে, আর কনফিগারেশন ট্রি লেখার যোগ্য করলেই সেই লেখাগুলি ঢাকা পড়ে না। নির্দিষ্ট ডিরেক্টরিটিকে তার কাজের জন্য প্রয়োজনীয় লেখার অনুমতি দিন, এমন মালিক ও মোড সহ যা আপনি ব্যাখ্যা করতে পারেন। যা কেবল পড়া হয় তার জন্য কেবল-পাঠযোগ্য অ্যাক্সেসকেই প্রাধান্য দিন।
প্রাইভেট কী-এর অনুমতি পলিসি ফাইল থেকে আলাদা রাখুন। রিসেটের পরে যে কী আবার পড়তে হয় তার চাহিদা আলাদা, আর প্রতিটি সংযোগে পড়া ক্লায়েন্ট ফাইলের চাহিদা আলাদা; দুটির উপর একটিই উদার মোড দিলে সমস্যা যা চায় তার চেয়ে বেশি অ্যাক্সেস বিলি হয়ে যায়। সংকীর্ণ মালিকানার একটি নিবেদিত ডেমন অ্যাকাউন্ট প্রশস্ত গ্রুপের চেয়ে সহজে নিরীক্ষণযোগ্য। কী-কে রিসেট পার হতে হলে, ডিরেক্টরি প্রশস্ত করার বদলে persist-key পুনরায়-পাঠ সরিয়ে দেয়।
আপনি যা পুনরুৎপাদন করতে পারেন সেই ঘটনা থেকেই সিদ্ধান্ত নিন
চলমান একটি টানেল কোডের মধ্য দিয়ে একটি পথ প্রমাণ করে। যে ঘটনার জন্য ফাইলটি দরকার সেটিই একমাত্র পরীক্ষা যা আপনার আগ্রহের ওপেন কভার করে — তা নতুন ক্লায়েন্ট সংযোগই হোক, প্রতিস্থাপিত রিভোকেশন ফাইল, অনুমোদিত সফট রিসেট বা পরিকল্পিত রিস্টার্ট। ঘটনাটি বেছে নিন, তা চালান, আর শেষ ত্রুটির বদলে প্রথম ত্রুটিটি ধরে রাখুন।
সফট রিসেটের ক্ষেত্রে একটি সিগন্যাল ও ইউনিটের লগ দেখায় কী-টি আবার পড়া হয়েছিল কি না। সিগন্যাল পাঠান, তারপর ইউনিট যে শেষ কয়েকটি লাইন লিখেছে তা পড়ুন:
systemctl kill -s SIGUSR1 [email protected]
journalctl -u [email protected] -n 40 --no-pagerশুধু সুবিধা কমানো হয়েছে বলে ধরে নেবেন না যে আক্রান্ত একটি ডেমন আর ফাইল পরিবর্তন করতে পারে না। সে এখনও কী করতে পারে তা নির্ভর করে তার অবশিষ্ট ক্রেডেনশিয়াল, তার ক্যাপাবিলিটি, যে ডিরেক্টরিগুলিতে সে লিখতে পারে এবং সে এখনও যে লেখার যোগ্য ডেসক্রিপ্টর ধরে আছে তার উপর। সুবিধা হ্রাস কর্তৃত্ব সংকুচিত করে, আর রানটাইম ওপেনের তালিকাই দেখায় তা কতদূর। সেই সীমানাটি কনফিগারেশনের পাশে লিখে রাখুন, যাতে পরের ব্যক্তিকে তা আবার আবিষ্কার করতে না হয়।