LXD কনটেইনার /dev/net/tun খুলতে পারছে না? unix-char এন্ট্রিটি দেখুন

LXD হোস্টের একটি ক্যারেক্টার ডিভাইসকে ডিভাইস নোড যোগ করে কনটেইনারে প্রকাশ করে, গেস্টকে সেটি তৈরি করতে শিখিয়ে নয়। কনটেইনারে /dev/net/tun না থাকলে হোস্টে ডিভাইসটি থাকতে পারে, তবু গেস্ট সেটি খুলতে নাও পারে। unix-char এন্ট্রি হলো সেই পথের ম্যানেজার-পক্ষের অর্ধেক, এবং এটি ইচ্ছাকৃতভাবেই একটি প্রিভিলেজড কনটেইনারের চেয়ে সংকীর্ণ। তাই হোস্ট নোড ও কনটেইনার নোড আলাদা যাচাইয়ের দাবি রাখে।

যন্ত্রপাতিটি চোখের সামনে রাখার মতোই ছোট: LXD একটি হোস্ট পথ সমাধান করে, ইনস্ট্যান্সের ভিতরে মিলে যাওয়া একটি নোড তৈরি করে এবং ডিভাইসটি কনটেইনারের ডিভাইস cgroup-এ যোগ করে। এরপর গেস্ট প্রসেসের নিজস্ব অনুমতি ও সক্ষমতা দরকার, তবেই সে নোডটি কোনো কাজে ব্যবহার করতে পারে।

unix-char এন্ট্রি আসলে কী বদলায়

একটি unix-char ডিভাইস LXD-কে বলে কনটেইনারের ভিতরে বেছে নেওয়া পথে হোস্টের একটি ক্যারেক্টার ডিভাইস প্রকাশ করতে। এন্ট্রির তিনটি গুরুত্বপূর্ণ অংশ আছে: ম্যানেজার যে ডিভাইস লেবেল ব্যবহার করে, হোস্টে source পথ এবং গেস্ট যে path দেখে। কেবল শেষ দুটি ডিভাইসটিকেই বর্ণনা করে। যেকোনো একটিতে টাইপো হলে ক্লায়েন্ট যে জায়গা কখনো খোলে না সেখানেই নোড তৈরি হয়।

হোস্টে ডিভাইসটি সাধারণত /dev/net/tun থাকে। কনটেইনারের ভিতরে আপনি একই পথ রাখতে পারেন বা অন্য পথ বেছে নিতে পারেন, তবে পথটি VPN ক্লায়েন্ট যা আশা করে তার সঙ্গে মিলতে হবে। /dev/net/tun রাখলে দ্বিতীয় কনফিগারেশন সমস্যা এড়ানো যায়, কারণ বেশিরভাগ ক্লায়েন্ট জিজ্ঞাসা না করেই সেই পথ খোলে।

ইনস্ট্যান্স চালু হলে বা ডিভাইস হটপ্লাগ হলে ম্যানেজার এন্ট্রিটি প্রয়োগ করে। এটি গেস্টে কোনো ড্রাইভার কপি করে না এবং টানেল ইন্টারফেস তৈরি করে না। এটি নোডটিকে দৃশ্যমান করে এবং কনটেইনারের ডিভাইস কন্ট্রোল গ্রুপের মধ্য দিয়ে অ্যাক্সেসের অনুমতি দেয়।

ডিভাইসটি গেস্টের ভিতরে নয়, ইনস্ট্যান্সে ঘোষণা করুন

LXD প্রশাসনিক প্রেক্ষাপট থেকে এন্ট্রিটি যোগ করুন, ইনস্ট্যান্সের নাম ও পরে চেনা যাবে এমন একটি লেবেল উল্লেখ করে। vpnbox নামের কনটেইনারের ক্ষেত্রে কমান্ডটি হলো:

lxc config device add vpnbox tun unix-char source=/dev/net/tun path=/dev/net/tun
lxc config device show vpnbox

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

কনটেইনারের ভিতরে ফাইল সম্পাদনা করা ভুল স্তর। স্টার্টআপ স্ক্রিপ্টে একটি mknod প্রিভিলেজড কনটেইনারে কাজ করছে বলে মনে হতে পারে, পরে পুনরায় তৈরি হলে মিলিয়ে যেতে পারে বা কম প্রিভিলেজড একটিতে ব্যর্থ হতে পারে। ইনস্ট্যান্সের ডিভাইস সেটের মালিক ম্যানেজার; নোডেরও মালিক সে-ই থাকুক।

মালিকানা ও মোড গেস্ট প্রসেসের সঙ্গে মিলান

unix-char এন্ট্রি কনটেইনারের ভিতরের নোডের জন্য uid, gid এবং mode সেট করতে পারে। প্রতিটি ব্যবহারকারীর জন্য ডিভাইস খুলে দেওয়া বা কনটেইনারকে প্রিভিলেজড মোডে বদলানোর বদলে, VPN ক্লায়েন্ট চালানো অ্যাকাউন্টের সঙ্গে মেলাতে এগুলো ব্যবহার করুন।

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

প্রসেসের আরও দরকার টানেল ইন্টারফেস কনফিগার করার সক্ষমতা, সাধারণত কনটেইনারের নেটওয়ার্ক নেমস্পেসে CAP_NET_ADMIN। ডিভাইস পাঠানো সেই সক্ষমতা দেয় না, আর সক্ষমতা দেওয়া ডিভাইস যোগায় না; এগুলো স্বতন্ত্র প্রয়োজন।

এন্ট্রি কী দেয় না তা জানুন

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

systemd আরেকটি বিধিনিষেধ যোগ করতে পারে। DeviceAllow বা কঠোর ডিভাইস নীতি থাকা একটি ইউনিট কনটেইনার ম্যানেজার যে নোড দিয়েছে তার অ্যাক্সেস অস্বীকার করতে পারে। নোডটি থাকা সত্ত্বেও সার্ভিস অনুমতি ত্রুটি জানালে ইউনিটের ডিভাইস নীতি দেখুন, এবং কনটেইনার প্রশস্ত করার বদলে সেই নীতিই বদলান।

হটপ্লাগ ঐচ্ছিক এবং স্পষ্ট। required=false থাকা এন্ট্রির একটি সোর্স পথ দরকার এবং হোস্ট ডিভাইস বদলালে তা আসতে বা যেতে পারে। এমন জীবনচক্র আসা-যাওয়া করা হার্ডওয়্যারের জন্য উপযুক্ত; VPN বুটে যে TUN ডিভাইস দরকার তার জন্য ঐচ্ছিক এন্ট্রি সার্ভিসকে তার পূর্বশর্ত তৈরি হওয়ার আগেই শুরু করতে দিতে পারে।

দৃশ্যমানতা, খোলা ও ইন্টারফেস এই ক্রমে যাচাই করুন

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

lxc exec vpnbox -- ls -l /dev/net/tun
lxc exec vpnbox -- sh -c 'test -c /dev/net/tun && echo char-device-ok'

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

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