VPN কন্টেইনারে NET_ADMIN: এটি কী এবং কোথায় পরিবর্তন করতে পারে

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

সক্ষমতা কী কী কভার করে

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

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

নেমস্পেসই বিস্ফোরণের ব্যাসার্ধ নির্ধারণ করে

নিজের ব্রিজ নেটওয়ার্কে থাকা কন্টেইনার নিজের loopback, নিজের ইন্টারফেস ও নিজের রাউটিং টেবিলে পৌঁছায়। সেখানে NET_ADMIN দেওয়া VPN ক্লায়েন্টকে হোস্টের রাউটিং সিদ্ধান্ত স্পর্শ না করেই একটি টানেল গড়তে দেয়, যা বেশিরভাগ কন্টেইনার ইমেজ ধরে নেয়।

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

তিনটি পূর্বশর্ত যা একটিতে মিলিয়ে দেওয়া হয়

VPN কন্টেইনারে স্টার্টআপ ব্যর্থতা সাধারণত তিনটি আলাদা জিনিসের একটিতে জড়িত থাকে: সক্ষমতা, টানেল ডিভাইস এবং প্রোটোকলের জন্য কার্নেল সমর্থন। তিনটিই একসঙ্গে দিলে কাজ করে, আর এটি পরের ব্যর্থতাটিকে দায়ী করা অসম্ভবও করে তোলে। একটি ন্যূনতম compose খণ্ড সক্ষমতা দেয় এবং ডিভাইস নোড স্পষ্টভাবে পাস করে:

services:
  vpn:
    image: example/vpn-client:latest
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun
    sysctls:
      - net.ipv4.conf.all.src_valid_mark=1

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

মোড নয়, সংকীর্ণ অপারেশন দিন

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

রুটলেস এবং ইউজার-নেমস্পেস স্থাপনা বাস্তবে সক্ষমতার অর্থ বদলে দেয়, কারণ প্রক্রিয়া এটি শুধু একটি ম্যাপ করা নেমস্পেসের ভিতরে রাখতে পারে। একটি রুটফুল উদাহরণ থেকে সক্ষমতার তালিকা রুটলেস রানটাইমে কপি করে একই পরিধি প্রত্যাশা করা দুপুরের সময় নষ্ট করার একটি সাধারণ উপায়।

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

পরিবর্তন যাচাই করুন এবং অনুমতিটি কেন আছে তা লিখে রাখুন

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

docker inspect --format '{{.HostConfig.CapAdd}} {{.HostConfig.NetworkMode}} {{.HostConfig.Privileged}}' vpn
docker exec vpn sh -c 'grep CapEff /proc/self/status'
docker exec vpn ip -br addr
docker exec vpn ip route

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

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

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