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 فائل میں اس کی وضاحت کرنے والے نوٹ کے بغیر مستقل ضرورت کے طور پر نہیں لکھا جانا چاہیے۔

ہر صلاحیت کے ساتھ وجہ لکھیں: کون سی کارروائی کو اس کی ضرورت تھی اور اس کے بغیر کیا ناکام ہوتا ہے۔ وہ نوٹ امیج کی تازہ کاریوں کے بعد بھی قائم رہتا ہے، اور یہی جائزہ لی گئی مراعات کی فہرست اور کاپی پیسٹ سے بڑھی فہرست کے درمیان فرق ہے۔