আপনার VPN প্রসেসের কোন Linux সক্ষমতা দরকার?
ইন্টারফেস সেটআপ, রুট, ডিভাইস অ্যাক্সেস এবং সাধারণ সকেট আলাদা আলাদা বিশেষাধিকার। CAP_NET_ADMIN দেওয়ার আগে ব্যর্থ অপারেশনটির নাম বলুন।
একটি VPN ডেমনের বিশেষাধিকারযুক্ত নেটওয়ার্ক অপারেশন প্রয়োজন, যদিও সাধারণ অ্যাপ্লিকেশন কোনো বিশেষাধিকার ছাড়াই আউটগোয়িং সকেট খোলে। এই ফাঁকটাই যেখানে বেশিরভাগ সক্ষমতা-সংক্রান্ত ভুল শুরু হয়: কেউ একটি অনুমতি ত্রুটি দেখে, পুরো সেটটাই দিয়ে দেয়, আর সেবাটি এমন কারণে কাজ করে যা পরে কেউ ব্যাখ্যা করতে পারে না। নিচের আলোচনা ব্যর্থ অপারেশন থেকে শুরু হয়, সেটিকে একটি কর্তৃত্বের সঙ্গে মেলায়, তারপর প্রসেসটি আসলে যে প্রসঙ্গে চলে তা যাচাই করে। সীমাহীন root হিসেবে চলা কিছু ডিপ্লয়মেন্টের জন্য বৈধ উত্তর, তবে এটি ডিফল্ট নয়, সিদ্ধান্ত হওয়া উচিত।
ব্যর্থ অপারেশন থেকে শুরু করুন
টিউটোরিয়াল পড়ার আগে ত্রুটিটি পড়ুন। ইন্টারফেস পরিবর্তনে «অপারেশন অনুমোদিত নয়», ডিভাইস নোড খুলতে অস্বীকৃতি এবং নিম্ন পোর্টে বাইন্ড ব্যর্থতা — এগুলো তিনটি ভিন্ন সমস্যা, তিনটি ভিন্ন অনুমতিসহ। প্রসেসটি চালু হয়ে যদি কেবল প্রথম রুট পরিবর্তনেই ব্যর্থ হয়, তাহলে সেটাও বলে যে ইন্টারফেস তৈরি আগেই সফল হয়েছে, যা উত্তরটিকে অনেক সংকুচিত করে।
সেবা বন্ধ রেখে ত্রুটিটি পুনরুৎপাদন করুন, তারপর বাস্তবায়ন অনুমতি দিলে একই ব্যবহারকারীর অধীনে ফোরগ্রাউন্ডে চালু করুন। যে ত্রুটি আপনি দেখতে পান তা অনুমান করতে হওয়া লগ লাইনের চেয়ে ভালো, আর এটি সক্ষমতা-সমস্যা এবং SELinux বা AppArmor প্রত্যাখ্যানের পার্থক্য স্পষ্ট করে।
প্রতিটি অপারেশন একটি কর্তৃত্বের সঙ্গে মেলান
টেবিলটি একটি শুরুর মানচিত্র, বাস্তবায়নের ডকুমেন্টেশনের বিকল্প নয়:
| Operation | Usual authority | Watch for |
|---|---|---|
| Create or configure tun/tap | CAP_NET_ADMIN in the relevant namespace | Creating the device and opening it are separate steps |
| Add routes, rules, firewall entries | CAP_NET_ADMIN | Same capability, different namespace than you think |
| Open /dev/net/tun | Device permissions, not a capability | Group membership or a udev rule may be enough |
| Raw sockets | CAP_NET_RAW | Needed by some user-space tunnel implementations |
| Bind a port below 1024 | CAP_NET_BIND_SERVICE | Irrelevant for most modern tunnel ports |
ওই টেবিলের দুটি সারিই মানুষ পরস্পরে গুলিয়ে ফেলে। /dev/net/tun খোলা একটি ফাইল-অনুমতির প্রশ্ন; আপনি যা খুলেছেন তা কনফিগার করতে কার্নেলকে অনুরোধ করা একটি সক্ষমতার প্রশ্ন। CAP_NET_ADMIN দিলে আপনার সেবা-ব্যবহারকারী যে ডিভাইস নোড পড়তে পারে না তা ঠিক হয় না, আর নোড ঠিক করলে আপনি রুট কর্তৃত্ব পান না। যেকোনোটি বদলানোর আগে দুটোই যাচাই করুন।
কার্নেল WireGuard এবং ইউজার-স্পেস টানেল প্রোগ্রামের চাহিদাও এক নয়। কার্নেল মডিউলের পথটি netlink-এর মাধ্যমে বিদ্যমান ইন্টারফেস কনফিগার করে, অন্যদিকে ইউজার-স্পেস বাস্তবায়নের ডিভাইসও লাগতে পারে এবং কিছু ট্রান্সপোর্টের জন্য র সকেটও।
প্রসঙ্গটি পড়ুন: সেবা, কনটেইনার নাকি শেল
হোস্টের নেটওয়ার্ক নেমস্পেসে একটি সক্ষমতা ইচ্ছাকৃতভাবে বিচ্ছিন্ন স্ট্যাকের একই অপারেশনের চেয়ে অনেক বেশি প্রভাব ফেলতে পারে। কনটেইনার রানটাইম সাধারণত সংকুচিত বাউন্ডিং সেট নিয়ে শুরু হয়; হোস্ট নেটওয়ার্ক ভাগ করে নেওয়া কনটেইনারে NET_ADMIN যোগ করা নিজস্ব নেটওয়ার্ক নেমস্পেস ও কোনো হোস্ট মাউন্ট নেই এমন কনটেইনারে যোগ করার চেয়ে অনেক বড় অনুমতি।
systemd ইউনিটের ক্ষেত্রে ইউনিট ফাইল যা বলে মনে হয় তা নয়, আসলে যা প্রয়োগ হয় তা পড়ুন: systemctl show -p CapabilityBoundingSet -p AmbientCapabilities কার্যকর মানগুলো জানায়, যেগুলো আপনার ভুলে যাওয়া কোনো drop-in সেট করতে পারে। কার্যকর মান চান, অভিপ্রেত মান কখনো নয়। Ambient সক্ষমতা গুরুত্বপূর্ণ, কারণ root নয় এমন সেবা সেগুলো ছাড়া exec জুড়ে সক্ষমতা হারায়।
প্যাকেজ বা ইমেজের সমর্থিত সেটআপকে ভিত্তি হিসেবে নিন। অন্য একটি টিউটোরিয়াল অন্য টুলের জন্য সেগুলো তালিকাভুক্ত করেছে বলে র-সকেট অনুমতি বা বিশেষাধিকারযুক্ত মোড যোগ করবেন না; ওই যুক্তি কিছুই বহন করে না এবং আপনার দেওয়া বিচ্ছিন্নতা কেড়ে নেয়। সন্দেহ হলে কিছুই দেবেন না এবং আপনার প্রয়োজনীয় সঠিক অপারেশনের জন্য বাস্তবায়নের নোট পড়ুন।
বিশেষাধিকার কমার পর কী ঘটে তা দেখুন
অনেক ডেমন বিশেষাধিকার নিয়ে শুরু করে, ইন্টারফেস কনফিগার করে, তারপর অবিশেষাধিকারী ব্যবহারকারীতে নামে এবং টানেল ধরে রাখে। সেই বিন্দু থেকে প্রসেস আর রুট যোগ করতে, ফায়ারওয়াল নিয়ম পুনর্লিখন করতে বা নতুন বিশেষাধিকারযুক্ত ডিভাইস খুলতে পারে না, যা ঠিক ততক্ষণ ঠিক থাকে যতক্ষণ পুনঃসংযোগের ঠিক সেটাই দরকার না হয়। পরবর্তী ফাইল পাঠ ও হুক সম্পাদন একই কারণে ব্যর্থ হতে পারে।
প্রথম সেকেন্ড নয়, পুরো জীবনচক্র পরীক্ষা করুন: সূচনা, নবায়ন বা পুনঃসংযোগ, এবং থামার সময় পরিষ্কার। ইন্টারফেস প্রথমবার সফলভাবে তৈরি হওয়া প্রমাণ করে না প্রতিটি পরবর্তী বিশেষাধিকারযুক্ত অপারেশন কাজ করবে, আর ব্যর্থতা সাধারণত উৎপাদনে ঘণ্টাখানেক পরে দেখা যায়।
ব্যবহারকারী পরিবর্তনের মধ্যেও টানেল খোলা রাখে এমন বাস্তবায়ন সাধারণত টানেল ও কী সংরক্ষণের অপশনের সঙ্গে তা জোড়া দেয়। systemd-এর দিকে সমতুল্য প্রশ্ন হলো ইউনিটের সক্ষমতা-সেট আপনার কনফিগার করা ব্যবহারকারী পরিবর্তন টিকে থাকে কি না।
অনুমতিটি ও তার কারণ লিখে রাখুন
সঠিক অনুমতি, এটি যে অপারেশন সক্ষম করে এবং যে ত্রুটি সারিয়েছে তা লিখুন। ডিপ্লয়মেন্ট নোটে এক লাইন — «ইউনিটের নেটওয়ার্ক নেমস্পেসে CAP_NET_ADMIN, পুনঃসংযোগের পর রুট পরিবর্তনের জন্য প্রয়োজন» — পরের ব্যক্তিকে আবার অনুমতি বাড়ানো থেকে থামাতে যথেষ্ট।
তারপর প্রতিটি আপগ্রেডের পর কার্যকর সেটটি আবার পড়ুন। ভেন্ডররা ফিচার যোগ করে, ইমেজ ডিফল্ট বদলায়, আর গত বছর অপ্রয়োজনীয় ছিল এমন সক্ষমতা কেউ না জানলেও ভারবহনকারী হয়ে উঠতে পারে।