OpenVPN داخل Docker لا يستطيع فتح /dev/net/tun: ما الذي ينقص

يمكن لصور الحاويات أن تحمل كل ملفات OpenVPN التنفيذية وملفات التهيئة التي تحتاجها ومع ذلك تفشل عند أول نداء شبكي. يذكر الخطأ /dev/net/tun لأن التطبيق طلب من النواة واجهة TUN ولم تكن للحاوية عقدة الجهاز ولا القدرة على إنشاء واحدة. هذان إذنان منفصلان، وإصلاح أحدهما يترك الآخر في مكانه تمامًا.

فصل الاثنين يتطلب أمرًا واحدًا لكل منهما. رسالة الخطأ بعد ذلك تخبرك عند أي حد كنت تقف في الواقع.

عقدة الجهاز والقدرة بابان

عقدة الجهاز كائن في نظام الملفات، لذا تحتاج الحاوية إلى رؤيته داخل فضاء أسماء التحميل الخاص بها. القدرة إذن، لذا تحتاج العملية إلى CAP_NET_ADMIN في فضاء الأسماء الذي ستُنشأ فيه الواجهة. تمرير الجهاز دون القدرة يمنحك عقدة تُفتح و ioctl يفشل. ومنح القدرة دون الجهاز يترك التطبيق عاجزًا عن فتح أي شيء إطلاقًا، ولهذا يظهر الاثنان عادة معًا في الأمثلة.

إعداد الأجهزة في Docker يُعيّن جهاز المضيف داخل الحاوية، بينما يضبط cap_add مجموعة القدرات. تركيب ربط للمسار نفسه يضع الملف في مرمى النظر دون تطبيق دلالات الوصول إلى الجهاز.

أعد إنتاجه خارج ملف 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 غير متاحة، وهذا إصلاح من جهة المضيف لا من جهة الحاوية. العقدة الموجودة التي يتعذر فتحها داخل الحاوية تشير إلى الوصول إلى الجهاز، وستقول الرسالة permission denied بدلًا من no such file. ترتيب هذين الفشلين هو التشخيص كله. دوّن أيّهما رأيت قبل تغيير أي علم.

الأخطاء بعد 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) والغائبة عن المجموعة الفعلية تتصرف بشكل مختلف عن قدرة لم تُمنح قط، و capsh يعرض كلتيهما. إذا كانت العقدة موجودة والقدرة حاضرة بينما لا يزال الإنشاء يفشل، فإن وقت التشغيل يفرض شيئًا آخر، مثل ملف seccomp أو سياسة AppArmor تقيّد العملية. هذا حد ثالث توثقه بيئة التشغيل لا التطبيق.

سجّل أعلام الحاوية والصورة والخطأ الدقيق من كل محاولة. يستطيع من يقرأ تلك الملاحظة لاحقًا معرفة أي باب كان مغلقًا دون تكرار التحقيق كله.