أهم درس من هذا الجزء من نقاش ProtonVPN/Gluetun بسيط: إن وضع qBittorrent على شبكة Docker تُسمى gluetun لا يساوي توجيه كل حركة مرور qBittorrent عبر حاوية Gluetun الخاصة بشبكة VPN. تمكّن المستخدم من تنزيل ملفات تورنت تجريبية بنجاح، بينما ظلت فحوصات عنوان IP العام داخل qBittorrent تُرجع عنوان مزوّد خدمة الإنترنت.
حصر المجتمع المشكلة في النهاية في دلالات شبكات Docker. ولمشاركة مكدس شبكة Gluetun، يحتاج qBittorrent إلى علاقة Compose مثل network_mode: "service:gluetun"، ويمكن لواجهة مستخدم ZimaOS الكتابة فوق هذا الإعداد أو إسقاطه إذا جرى تعديل المكدس لاحقًا بطرق غير متوافقة.
كان Gluetun متصلًا بالفعل
كان استكشاف الأخطاء وإصلاحها في المصدر قد وصل بالفعل إلى نقطة أظهرت فيها سجلات Gluetun عنوان IP عامًا لشبكة VPN ونجاح بدء النفق. وهذا يعني أن حاوية VPN نفسها لم تكن المشكلة المتبقية.
كان السؤال التالي هو ما إذا كان qBittorrent يستخدم بالفعل مساحة أسماء الشبكة نفسها.
لم يكن qBittorrent يدير شبكة VPN خاصة به
حددت القائمة المنسدلة للشبكة في ZimaOS شبكة Docker
gluetun جعل qBittorrent يشارك مقطعًا شبكيًا، لكنه لم يجعله يشارك مساحة أسماء شبكة Gluetun.فصل المجيب بشكل صحيح بين مفهومين في Docker:
- الانضمام إلى شبكة Docker مخصصة للمستخدم نفسها؛
- مشاركة مساحة أسماء شبكة خدمة أخرى عبر
network_mode: service:gluetun.
النموذج الثاني فقط يجبر جميع حركة مرور شبكة qBittorrent على المرور عبر مكدس Gluetun.
أثبت اختبار عنوان IP العام أن qBittorrent كان يتجاوز شبكة VPN
أوصى المجتمع بالتحقق من عنوان IP العام من داخل حاوية qBittorrent ومقارنته بعنوان IP الخاص بشبكة VPN الظاهر في سجلات Gluetun.
أجرى المستخدم الاختبارات، وأعاد كلاهما عنوان IP العادي لمزوّد خدمة الإنترنت. وكان ذلك أقوى دليل في نقاش الصفحة الثانية، لأنه قاس مسار حركة البيانات الفعلي بدلًا من استنتاجه من أسماء الواجهات.
يجب أن يصمد network_mode أمام استيراد Compose في ZimaOS
اكتشف مشارك لاحق أن تصدير التطبيق بعد تعديلات واجهة ZimaOS قد يُظهر ما يلي: network_mode السطر مفقود. وأفادوا بنجاح بعد استيراد تعريف Compose حافظ على علاقة وضع الشبكة وتجنب الإعدادات غير المتوافقة المنافذ/الشبكات الإعدادات على خدمة qBittorrent.
هذا سلوك تم التحقق منه مجتمعيًا في ZimaOS لعام 2026، وليس ضمانًا رسميًا من IceWhale بشأن كل محرر YAML حالي في متجر التطبيقات.
أبقِ Gluetun وqBittorrent في مشروع Compose واحد
في النقاش الأصلي، أوضح المجتمع أن الخدمة:gluetun يعمل ذلك عندما تكون الخدمتان كلتاهما جزءًا من مشروع Compose نفسه. عندئذٍ يشارك qBittorrent مساحة أسماء الشبكة الخاصة بـ Gluetun، ولذلك تُنشر واجهة الويب والمنافذ الواردة لـ qBittorrent على خدمة Gluetun بدلًا من ذلك.
يستخدم مجتمع Gluetun الأساسي بنية Docker Compose نفسها. راجع مشروع Gluetun الحالي وإعدادات مزود الخدمة قبل نسخ متغيرات البيئة القديمة.
استخدم بيانات اعتماد ProtonVPN لـ WireGuard، وليس كلمة مرور حساب Proton العادية
أثبت النقاش الأوسع خطأً شائعًا آخر: يحتاج إعداد WireGuard في Gluetun إلى قيم مفتاح/إعداد WireGuard المناسبة لـ Proton VPN، وليس كلمة مرور تسجيل الدخول العادية للحساب.
لا تنشر مفتاح WireGuard الخاص في منتدى عام مطلقًا. فقد كشفه المستخدم الأصلي عن طريق الخطأ وألغاه لاحقًا على نحو صحيح.
تحقّق من مسار القطع، وليس من المسار السلس فقط
بعد تشغيل الحزمة المدمجة، تحقّق من التالي:
- تُظهر سجلات Gluetun عنوان IP العام المتوقع لشبكة VPN؛
- يطابق عنوان IP العام الصادر من qBittorrent عنوانه؛
- يفقد qBittorrent إمكانية الوصول إلى الإنترنت إذا أُوقف نفق Gluetun أو أصبح غير سليم؛
- تبقى واجهة الويب قابلة للوصول عبر المنفذ المنشور على Gluetun.
يؤكد هذا أن التطبيق لا ينتقل بصمت إلى استخدام اتصال مزود خدمة الإنترنت.
لا تحتاج جميع تطبيقات ARR إلى العمل خلف شبكة VPN
ناقش النقاش الأصلي المطول أيضًا وضع حزمة ARR بأكملها خلف شبكة VPN لتبسيط الاتصال. قد ينجح ذلك، لكنه ليس ضروريًا دائمًا. يوجّه كثير من المستخدمين عميل التنزيل فقط عبر Gluetun، بينما تبقى Sonarr/Radarr على شبكة Docker العادية وتتواصل عبر مسارات ومنافذ مضيفة/حاوية محددة صراحةً.
اختر البنية عن قصد، بدلًا من وضع كل خدمة خلف النفق لمجرد أن ذلك يحل مشكلة اتصال واحدة.
انشر منافذ qBittorrent على Gluetun، وليس على qBittorrent
عندما يستخدم qBittorrent network_mode: "service:gluetun"، فلم يعد يمتلك مساحة أسماء شبكة مستقلة. وهذا يعني ضرورة نشر واجهة WebUI الخاصة به وأي منافذ BitTorrent واردة على خدمة Gluetun بدلًا من خدمة qBittorrent.
إذا اختفت واجهة qBittorrent WebUI بعد الانتقال إلى وضع الشبكة المشتركة، فتحقق من قائمة منافذ Gluetun قبل استنتاج أن التطبيق فشل في التشغيل.
احذر عند تحرير الحزمة المستوردة في واجهة ZimaOS
يُعد التقرير المجتمعي اللاحق مهمًا بشكل خاص لمستخدمي ZimaOS: احتوى ملف Compose المستورد في الأصل على network_mode، لكن بعد تغييرات واجهة المستخدم لم يعد التعريف المُصدَّر كذلك. وقال المشارك نفسه إن إزالة التعريفات المتعارضة المنافذ و الشبكات أدى إدخال العناصر مرة أخرى واستيراد الحزمة إلى الحفاظ على العلاقة العاملة.
لا يثبت هذا أن كل تعديل حالي لملفات YAML في ZimaOS سيتصرف بهذه الطريقة، لكنه يعني ضرورة إعادة فحص Compose المُنشأ بعد تغيير إعدادات الشبكة عبر المحرر الرسومي.
طوبولوجيا Docker قابلة لإعادة الاستخدام مع مزوّدي VPN، لكن بيانات الاعتماد ليست كذلك
تتضمن الصفحة 2 مثالًا لاستكشاف أخطاء Surfshark وإصلاحها، بينما بدأ النقاش الأصلي باستخدام ProtonVPN. الدرس المتعلق بشبكات Docker واحد: يوفر Gluetun النفق، ويجب أن يوجّه qBittorrent حركة المرور عبر مساحته الخاصة. المفاتيح الخاصة بالمزوّد، ومحددات الخوادم، وخيارات إعادة توجيه المنافذ، وقيم المصادقة ليست قابلة للتبادل.
أنشئ دائمًا بيئة Gluetun من إعدادات المزوّد الحالية بدلًا من نسخ قيم Surfshark أو Proton الخاصة بمستخدم آخر.
لا تلصق مفاتيح WireGuard الخاصة في لقطات الشاشة العامة أو منشورات المنتديات
كشف صاحب المنشور الأصلي عن طريق الخطأ مفتاح WireGuard خاصًا، وأبطله بعد أن حذّره مشارك آخر. اعتبر أي مفتاح VPN منشور مخترقًا وغيّره فورًا.
عند طلب المساعدة، احجب المفاتيح الخاصة والرموز المميزة وكلمات المرور وملفات تعريف الارتباط ومعرّفات حسابات المزوّد، مع إبقاء السجلات غير السرية ورسائل الخطأ ظاهرة.
الأسئلة الشائعة حول توجيه Gluetun
هل يؤدي الانضمام إلى شبكة Docker باسم gluetun إلى توجيه حركة المرور عبر شبكة VPN؟
لا. أثبت المصدر أن qBittorrent يمكنه البقاء على مسار مزود خدمة الإنترنت أثناء اتصاله بتلك الشبكة.
ما الإعداد الذي يشارك مساحة أسماء شبكة Gluetun؟
يستخدم نمط Compose المصدر والمصب network_mode: "service:gluetun".
كيف تتحقق من المسار؟
قارن عنوان IP العام الظاهر من داخل qBittorrent بعنوان IP الخاص بشبكة VPN الذي يعرضه Gluetun.
