কেন বিশেষাধিকারযুক্ত মোড VPN-এর প্রয়োজনের চেয়ে বিস্তৃত

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

ফ্ল্যাগটি আসলে কী বদলায়

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

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

প্রতিটি ত্রুটিকে একটি পূর্বশর্তের সাথে মেলান

ত্রুটির বার্তাটি আপনাকে বলে কোন পূর্বশর্তটি অনুপস্থিত, যদি আপনি এটি চাপা দেওয়ার আগে পড়েন। ডিভাইস নোড নিয়ে একটি বার্তা ডিভাইসটির নাম বলে, অনুমোদিত নয় এমন একটি অপারেশন নিয়ে বার্তা একটি সামর্থ্যের নাম বলে, আর মডিউল বা sysctl নিয়ে বার্তা কার্নেল সমর্থনের নাম বলে। এগুলোর প্রতিটির আলাদা সমাধান আছে, এবং এর মধ্যে কেবল একটি সামর্থ্য।

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

লক্ষণ নয়, প্রয়োজনীয়তা যাচাই করুন

ইমেজ যে সর্বনিম্ন ইনভোকেশন নথিভুক্ত করে সেখান থেকে শুরু করুন, এটি চালান, এবং ব্যর্থতার সঠিক লেখাটি রাখুন। তারপর একবারে একটি অনুমতি যোগ করুন এবং কোন সংযোজন ফলাফল বদলেছে তা লিখে রাখুন।

ls -l /dev/net/tun
docker run --rm --cap-add NET_ADMIN --device /dev/net/tun image:tag
ip -br link show type tun

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

হোস্টে ডিভাইসের অনুমতিগুলোও যাচাই করুন, কারণ সঠিকভাবে দেওয়া একটি ডিভাইস নোড ভুল গ্রুপ মালিকানার সাথে অনুপস্থিত অনুমতির মতোই একই ত্রুটি তৈরি করে।

যে সংকীর্ণতম অনুমতি কাজ করে তা লিপিবদ্ধ করুন

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

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