Docker-এ OpenVPN /dev/net/tun খুলতে পারে না: কী অনুপস্থিত

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

এগুলো আলাদা করতে প্রতিটির জন্য একটি করে কমান্ড লাগে। পরের ত্রুটি বার্তা আপনাকে বলে দেয় আপনি আসলে কোন সীমান্তে দাঁড়িয়ে ছিলেন।

ডিভাইস নোড এবং সক্ষমতা দুটি দরজা

ডিভাইস নোড একটি ফাইলসিস্টেম বস্তু, তাই কন্টেইনারকে এটি তার নিজের মাউন্ট নেমস্পেসে দেখতে হয়। সক্ষমতা একটি অনুমতি, তাই প্রসেসের ইন্টারফেসটি যে নেমস্পেসে তৈরি হবে সেখানে CAP_NET_ADMIN দরকার। সক্ষমতা ছাড়া ডিভাইসটি পাস করলে আপনি এমন একটি নোড পান যা খোলে আর একটি ioctl যা ব্যর্থ হয়। ডিভাইস ছাড়া সক্ষমতা দিলে অ্যাপ্লিকেশন কিছুই খুলতে পারে না, এজন্যই উদাহরণে দুটো সাধারণত একসাথে দেখা যায়।

Docker-এর devices সেটিং হোস্ট ডিভাইসটিকে কন্টেইনারে ম্যাপ করে, আর cap_add সক্ষমতা সেটটি সমন্বয় করে। একই পথের একটি bind mount ডিভাইস অ্যাক্সেসের অর্থবোধ প্রয়োগ না করেই ফাইলটিকে দৃষ্টির মধ্যে রাখে।

Compose ফাইলের বাইরে এটি পুনরুৎপাদন করুন

সার্ভিস সম্পাদনার আগে যাচাই করুন যে হোস্টের কাছে ডিভাইসটি আছে এবং একটি খালি কন্টেইনার একটি ইন্টারফেস তৈরি করতে পারে। নিচের কমান্ডটি ইচ্ছাকৃতভাবে ন্যূনতম, এবং এর একমাত্র উদ্দেশ্য হোস্ট সমস্যাকে compose সমস্যা থেকে আলাদা করা। এটি ব্যর্থ হলে কোনও compose পরিবর্তন সাহায্য করবে না।

ls -l /dev/net/tun
docker run --rm --cap-add NET_ADMIN --device /dev/net/tun:/dev/net/tun alpine sh -c 'apk add -q iproute2 && ip tuntap add dev tun9 mode tun && ip link show tun9'

হোস্টে নোড অনুপস্থিত থাকলে বোঝায় tun মডিউলটি নেই, যা কন্টেইনারের নয় বরং হোস্টের দিকের সমাধান। নোড থাকা সত্ত্বেও কন্টেইনারের ভিতরে খোলা না গেলে তা ডিভাইস অ্যাক্সেসের দিকে ইঙ্গিত করে, এবং বার্তাটি no such file নয় বরং permission denied বলবে। এই দুটি ব্যর্থতার ক্রমই পুরো রোগনির্ণয়। কোনও ফ্ল্যাগ পরিবর্তনের আগে আপনি কোনটি দেখেছেন তা লিখে রাখুন।

TUN-এর পরের ত্রুটিগুলো ভিন্ন সমস্যা

ইন্টারফেস দেখা মাত্র পরবর্তী ব্যর্থতার মালিক আলাদা। প্রমাণীকরণ ত্রুটির অর্থ টানেল সার্ভারে পৌঁছেছে এবং শংসাপত্র প্রত্যাখ্যাত হয়েছে, তাই সক্ষমতা পরিবর্তন সাহায্য করবে না। টানেল প্রতিষ্ঠিত হওয়ার পরও অ্যাপ্লিকেশন ব্যর্থ হলে তা রুট, ফরওয়ার্ডিং, কন্টেইনারের ভিতরে DNS রেজোলিউশন বা কন্টেইনারের নিজস্ব নেটওয়ার্ক বিন্যাসের দিকে ইঙ্গিত করে। এর প্রত্যেকটি সাধারণ নেটওয়ার্কিং প্রশ্ন যা TUN অনুমতি উত্তর দিতে পারে না। প্রতিটি পরিবর্তনের পরে মূল পরীক্ষাটি পুনরাবৃত্তি করলে ব্যর্থতাগুলো একটি ধারণায় মিশে যাওয়া থেকে বিরত থাকে।

একটি কার্যকর উদাহরণ থেকে প্রতিটি সেটিং কপি করাই ন্যূনতম সমাধানকে অপাঠ্য সার্ভিস সংজ্ঞায় পরিণত করার উপায়। এই ডিপ্লয়মেন্টের যেগুলো দরকার শুধু সেগুলোই নিয়ে আসুন এবং প্রতিটি কেন আছে তা লিখে রাখুন।

কন্টেইনারের ভিতরে ইন্টারফেস যাচাই করুন

ইন্টারফেস এবং সক্ষমতা সেটটি যাচাই করুন হোস্ট থেকে নয়, চলমান কন্টেইনারের ভিতর থেকে। নিচের কমান্ডগুলো ডিভাইস নোড, সক্ষমতার তালিকা এবং আদৌ একটি ইন্টারফেস তৈরি করা যায় কিনা দেখায়। ক্লায়েন্ট চালানো একই কন্টেইনারে সেগুলো চালান, এবং ইমেজ ন্যূনতম হলে টুলিং ইনস্টল করুন।

ls -l /dev/net/tun
capsh --print | grep -i net_admin
ip link add dev tun9 type tun && ip link show tun9

bounding set-এ উপস্থিত কিন্তু effective set-এ অনুপস্থিত একটি সক্ষমতা কখনও দেওয়া হয়নি এমন সক্ষমতার থেকে ভিন্নভাবে আচরণ করে, এবং capsh দুটোই দেখায়। নোড থাকা এবং সক্ষমতা থাকা সত্ত্বেও তৈরি ব্যর্থ হলে রানটাইম অন্য কিছু প্রয়োগ করছে, যেমন একটি seccomp প্রোফাইল বা একটি AppArmor নীতি যা অপারেশনটি সীমিত করে। এটি তৃতীয় একটি সীমান্ত, যা অ্যাপ্লিকেশন নয় বরং রানটাইম নথিভুক্ত করে।

কন্টেইনার ফ্ল্যাগ, ইমেজ এবং প্রতিটি প্রয়াসের সঠিক ত্রুটি লিখে রাখুন। ওই নোট পড়া পরবর্তী ব্যক্তি পুরো তদন্ত পুনরাবৃত্তি না করেই বলতে পারবে কোন দরজাটি বন্ধ ছিল।