NET_ADMIN في حاوية VPN: ما الذي يمكنه تغييره وأين

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

اقرأ توثيق الصورة نفسه لمعرفة أي sysctls تحتاج، لأن 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 كمتطلب دائم دون ملاحظة تشرح ذلك.

اكتب السبب بجانب كل قدرة: أي عملية احتاجتها وما الذي يفشل بدونها. تلك الملاحظة تصمد أمام تحديثات الصور، وهي الفرق بين قائمة صلاحيات مراجَعة وأخرى نبتت بالنسخ واللصق.