توجيه حاويات Docker عبر VPN باستخدام Gluetun

لماذا تختفي المنافذ عند توجيه حاويات Docker عبر VPN

لتوجيه حاويات Docker عبر VPN، امنح إحدى الحاويات النفق، ثم اربط الحاويات الأخرى بمساحة أسماء الشبكة الخاصة بها باستخدام network_mode: "service:gluetun". هذا الربط هو الجزء الذي يسبب الالتباس. عند ربط الحاوية، لا تعود لها شبكة خاصة بها، لذلك تختفي معها المنافذ المنشورة واسم خدمة Docker الخاص بها. انشر المنافذ على حاوية VPN بدلاً من ذلك، ويمكن للحاويات الأخرى الوصول إلى التطبيق باستخدام اسم حاوية VPN.

اترك كتلة ports: في الحاوية المرتبطة، وسيرفض Docker إنشاءها:

Error response from daemon: conflicting options: port publishing and the container type network mode

الأداة المستخدمة هنا هي Gluetun، وهي حاوية تتصل بموفر VPN تجاري عبر WireGuard أو OpenVPN، وتستخدم جداراً نارياً خاصاً بها. الإصدار v3.41.3 هو الإصدار الحالي اعتباراً من October 2026. تستخدم الأمثلة Mullvad مع WireGuard، لذلك تحتاج إلى حساب ومفتاح من موفر الخدمة. إذا كنت تفضل إنهاء النفق على أجهزة تملكها، فإن تشغيل خادم WireGuard الخاص بك على VPS ينشئ الطرف الآخر، بينما يغلّف wg-easy في Docker ذلك ضمن واجهة ويب.

ما الذي يفعله network_mode: "service:gluetun" فعلياً

يحصل كل Docker container عادةً على network namespace خاص به: واجهاته الخاصة، وجدول التوجيه الخاص به، وقواعد جدار الحماية الخاصة به، ومقابس الاستماع الخاصة به. يتجاوز الوضع service: هذه الخطوة، ويشغّل الـcontainer داخل namespace الخاص بـgluetun. يعني استخدام namespace واحد وجود عنوان IP واحد، وهذا يغيّر ستة أمور.

• لا يملك التطبيق عنواناً خاصاً به. عنوانه هو عنوان gluetun.
• لا يتصل التطبيق بأي Docker network، لذلك لا يُسجَّل اسم خدمته ولا يمكن حله. يجب أن تستخدم الـcontainers الأخرى gluetun.
• تتصل الـcontainers الموجودة داخل namespace الواحد ببعضها عبر localhost.
• لا يمكن لـcontainerين في namespace واحد الاستماع على المنفذ نفسه. توضح وثائق Gluetun ذلك صراحةً: لا يوجد حل بديل.
• ترتبط Capabilities بالـcontainer، لا بالـnamespace. يملك Gluetun كلاً من NET_ADMIN و/dev/net/tun لأنه ينشئ واجهة النفق. ولا يرث الـcontainer المتصل هذه الصلاحيات.
• يرفض Compose أي ملف تضبط فيه إحدى الخدمات كلاً من network_mode وnetworks. صِل gluetun بشبكاتك، وسيعمل التطبيق عبره.

يؤدي إعادة تشغيل gluetun إلى قطع اتصال كل ما هو متصل به. هذا سلوك موثق، ولذلك يعيد gluetun تشغيل عملية VPN داخل الـcontainer بدلاً من الخروج عند فشل الاتصال. بعد إعادة تشغيل gluetun أو إعادة إنشائه يدوياً، أعد تشغيل الـcontainers المتصلة به.

ملف Compose الذي يعمل

services:
  gluetun:
    image: qmcgaw/gluetun:v3
    container_name: gluetun
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun
    environment:
      - VPN_SERVICE_PROVIDER=mullvad
      - VPN_TYPE=wireguard
      - SERVER_CITIES=Amsterdam
      - TZ=Europe/Amsterdam
    env_file:
      - ./gluetun.env
    volumes:
      - ./gluetun:/gluetun
    ports:
      - 127.0.0.1:8080:8080/tcp
    restart: unless-stopped

  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrent
    network_mode: "service:gluetun"
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Amsterdam
      - WEBUI_PORT=8080
    volumes:
      - ./qbittorrent:/config
      - ./downloads:/downloads
    depends_on:
      gluetun:
        condition: service_healthy
    restart: unless-stopped

تمثل العلامة :v3 أحدث إصدار مستقر في السلسلة v3. وتشير العلامة :latest إلى آخر commit في فرع master، وهو مسار التطوير المتغير. لذلك ثبّت :v3 على جهاز لا تريد أن تستكشف أعطاله يوم الثلاثاء.

يجب أن تطابق WEBUI_PORT=8080 المنفذ المنشور، لأن qBittorrent يستمع داخل مساحة أسماء gluetun، وتوجّه قاعدة النشر حركة مرور الخادم إلى المنفذ 8080 هناك. إذا غيّرت أحد الرقمين دون الآخر، فلن يستجيب المنفذ لأي شيء. تُبقي 127.0.0.1:8080:8080 واجهة الويب على عنوان loopback المحلي للخادم. أما 8080:8080 المجردة فتنشر المنفذ على كل واجهة وتضيف قاعدة جدار ناري خاصة بها، وهذا ما يتيح لـمنافذ Docker المنشورة تجاوز ufw مباشرة.

شغّل الحاويات، ثم تحقق منها بالترتيب التالي:

docker compose up -d
docker compose ps
docker compose logs gluetun | tail -30

يجب أن تعرض docker compose ps gluetun بالحالة healthy، وqbittorrent بالحالة running. ثم تحقّق من عنوان الخروج من داخل مساحة الأسماء. هذا هو الاختبار الذي يحدد نتيجة كل ما سواه:

docker run --rm --network=container:gluetun alpine:3.22 sh -c "apk add wget && wget -qO- https://ipinfo.io"

يجب أن يحتوي الحقل ip في JSON على عنوان موفر VPN لديك. إذا كان العنوان الخاص بخادمك، فهذا يعني أن التطبيق ليس داخل النفق، ولن يعمل أي مما يلي كما هو موضح.

أبقِ المفاتيح خارج ملف Compose

يحتوي gluetun.env على بيانات الاعتماد، ويبقى خارج مستودع git:

WIREGUARD_PRIVATE_KEY=wOEI9rqqbDwnN8/Bpp22sVz48T71vJ4fYmFWujulwUU=
WIREGUARD_ADDRESSES=10.64.222.21/32

تأتي القيمتان من ملف إعداد WireGuard تنشئه في منطقة حسابك لدى موفّر الخدمة. اضبط وضع الملف على 600. كن واضحاً بشأن ما يوفّره ذلك: يبقى المفتاح خارج مستودعك، لكن docker inspect gluetun يطبع جميع متغيرات البيئة لأي شخص يمكنه الوصول إلى Docker socket. يشرح ملفات البيئة والأسرار في Docker Compose الخيارات الأقوى.

كيفية اتصال حاوية خارج النفق بحاوية داخله

يعمل الاتصال في الاتجاهين، ويستخدم كل اتجاه اسماً مختلفاً. تحتاج الحاويتان إلى شبكة Docker مشتركة، وهي شبكة gluetun، لأن الحاوية المرتبطة لا تملك شبكة خاصة بها. يوضّح كيفية توصيل شبكات Docker Compose الإعدادات الافتراضية.

للاتصال من الخارج إلى الداخل، استخدم اسم gluetun والمنفذ الذي يستمع عليه التطبيق. تصل حاوية reverse proxy إلى واجهة qBittorrent على gluetun:8080. لا تحتاج إلى إدخال ports: لهذا الغرض، لأن حركة المرور بين الحاويات تبقى على شبكة Docker ولا تمر عبر منفذ على المضيف.

للاتصال من الداخل إلى الخارج، استخدم اسم خدمة الحاوية الأخرى، مثل postgres:5432. يحل Gluetun أسماء الحاويات الأخرى من داخل مساحة الأسماء الخاصة به منذ الإصدار v3.41، لذلك ثبّت هذا الإصدار أو إصداراً أحدث إذا تعذّر حل اسم.

يحدد جدار Gluetun الناري الجهات التي يمكنها فتح اتصال به. يُسمح بحركة المرور القادمة من شبكة Docker الخاصة بـgluetun. أما العميل الموجود على شبكة فرعية مختلفة، مثل حاسوب محمول على شبكتك المحلية أو حاوية على شبكة bridge منفصلة، فيحتاج إلى مسار عودة يسمح به جدار Gluetun الناري والتوجيه:

FIREWALL_OUTBOUND_SUBNETS=192.168.1.0/24

المعنى الموثّق دقيق: شبكات فرعية مفصولة بفواصل يُسمح لـGluetun والحاويات التي تشاركه مكدس الشبكة بالوصول إليها.

تُعد الاتصالات الواردة من الإنترنت مشكلة منفصلة. يصل أقران عميل torrent من جهة VPN، لذلك لا يفيد نشر المنفذ 6881 على المضيف. تحتاج إلى منفذ مُعاد توجيهه من موفّر الخدمة، وإدراج هذا المنفذ في FIREWALL_VPN_INPUT_PORTS، الذي يسمح بالمنافذ القادمة من جهة خادم VPN. لا يدعم Mullvad، المستخدم في هذا المثال، إعادة توجيه المنافذ، لذلك تحتاج إلى موفّر يدعمها. هذه هي النقطة التي تتركها معظم حِزم الوسائط المبنية باستخدام Docker Compose معطّلة.

مفتاح الإيقاف: ماذا يحدث عند انقطاع النفق

يبرر هذا النمط تعقيده عند حدوث الفشل. تشارك الحاوية المرتبطة واجهات Gluetun وجدول التوجيه الخاص بها. يحظر جدار Gluetun الناري حركة الإنترنت العادية خارج النفق، مع السماح بنقطة نهاية خادم VPN، وحركة Docker المحلية، والاستثناءات المكوّنة. هذا الجدار الناري هو ما يمنع الرجوع إلى الواجهة العادية عند انقطاع النفق. لا توجد فترة تتسرّب فيها الحزم عبر الواجهة العادية أثناء إعادة اتصال العميل.

يراقب Gluetun اتصاله بنفسه. كل دقيقة، يرسل طلب صدى ICMP (أي ping) إلى العناوين الموجودة في HEALTH_ICMP_TARGET_IPS، والتي تكون 1.1.1.1,8.8.8.8 افتراضياً. إذا لم يكن ICMP مسموحاً به، يعود هذا الفحص الصغير إلى استخدام استعلام DNS عبر UDP بنص واضح. كل خمس دقائق، ينشئ اتصال TCP وTLS (أمن طبقة النقل) كاملاً إلى HEALTH_TARGET_ADDRESSES، والقيمة الافتراضية هي cloudflare.com:443,github.com:443. عند فشل هذه الاتصالات، يعيد تشغيل VPN داخل الحاوية ويسجل ذلك:

WARN [vpn] restarting VPN because it failed to pass the healthcheck: periodic check: dialing: dial tcp4: lookup cloudflare.com: i/o timeout

اقرأ سجلات الحاوية المرتبطة مع وضع هذا التسلسل في الاعتبار. إن الأسطر مثل connection refused وoperation not permitted وi/o timeout داخل التطبيق هي نتائج نفق متوقف، وليست أسباباً له. توضح وثائق Gluetun ذلك صراحة، لأن المستخدمين يبلغون عن النتيجة ويبحثون عنها لساعات.

يكون HEALTH_RESTART_VPN=on مفعّلاً افتراضياً، وينبغي أن يظل كذلك. عطّله فقط أثناء تصحيح فشل محدد، لأن النفق المتوقف يظل متوقفاً عند تعطيله.

ترتيب بدء المكدس بعد تشغيل النفق

تتضمن الصورة فحصاً لصحة Docker:

HEALTHCHECK --interval=5s --timeout=5s --start-period=10s --retries=3 CMD /gluetun-entrypoint healthcheck

يشغّل هذا الأمر نسخة ثانية قصيرة العمر من gluetun، وتستعلم هذه النسخة عن خادم الصحة الخاص بالنسخة العاملة على http://127.0.0.1:9999/. يستجيب النفق العامل بـ200 OK. أما النفق المتعطل فيستجيب بـ500 Internal server error مع سلسلة خطأ، ويضع Docker الحاوية في حالة غير سليمة بعد ثلاث عمليات فحص فاشلة متتالية.

ينتظر condition: service_healthy تحقق ذلك الشرط. أما depends_on: [gluetun] العادي فلا ينتظر سوى بدء الحاوية. يحدث ذلك قبل اكتمال المصافحة بعدة ثوانٍ، ولذلك يبدأ التطبيق مع شبكة متوقفة، وغالباً ما يتخلى عن أول محاولة اتصال له. يشرح فحوصات الصحة في Docker Compose الصياغة وحقول التوقيت.

هناك حدّ يسبب مشكلات لبعض المستخدمين. يقيّم Compose هذا الشرط عند بدء المكدس. ولا يوقف التطبيق أو يعيد تشغيله لاحقاً إذا أصبحت gluetun غير سليمة. تتولى آلية المعالجة التلقائية الداخلية في gluetun هذه الحالة بدلاً من ذلك. ولهذا تعيد تشغيل عملية VPN وليس الحاوية.

تحقّق من تسرّب DNS قبل الوثوق بالإعداد

يُعد DNS (نظام أسماء النطاقات) التسرّب الذي يستمر حتى عند عمل النفق بشكل صحيح. يشغّل Gluetun محلّل أسماء خاصاً به داخل مساحة الأسماء، ويمرّر الاستعلامات عبر DoT (DNS عبر TLS) إلى Cloudflare افتراضياً: DNS_UPSTREAM_RESOLVER_TYPE=dot وDNS_UPSTREAM_RESOLVERS=cloudflare. اترك القيمتين كما هما، وستكون عمليات البحث مشفّرة وتمر عبر النفق.

الإعداد الذي يتسبب في ذلك عند توجيهه إلى محلّل أسماء محلي هو DNS_UPSTREAM_PLAIN_ADDRESSES. يلجأ إليه المستخدمون عندما يفشل حل اسم ما ويريدون من جهاز التوجيه أو من محلّل مزوّد الخدمة الإجابة بدلاً من ذلك. تحذّر وثائق Gluetun من أن الاستعلامات المرسلة إلى محلّل أسماء على جسر Docker أو على الشبكة المحلية تتسرّب خارج نفق VPN. ولا يعني استخدام محلّل أسماء عام غير مشفّر أن الاستعلامات لا تمر عبر النفق، لكن مزوّد VPN يستطيع قراءتها وتعديلها. وتتناول DNS الذي يتوقف عن الحل عبر نفق WireGuard الخطأ نفسه في إصدار WireGuard.

لاختبار ذلك، اضبط SHADOWSOCKS=on وSHADOWSOCKS_PASSWORD على gluetun، وانشر 8388:8388/tcp و8388:8388/udp، ثم اتصل باستخدام عميل Shadowsocks مُعدّ لتمرير DNS عبر UDP، وافتح اختباراً لتسرّب DNS. يجب أن تذكر النتيجة مزوّدك أو Cloudflare، لا جهاز التوجيه المنزلي مطلقاً. تحذّر وثائق Gluetun نفسها من أن بعض اختبارات التسرّب تعرض نتائج غير معتادة، لأن محلّل الأسماء داخل مساحة الأسماء وسيط تخزين مؤقت محلي، وليس الخادم الذي يجيب عن الاستعلام في النهاية. اعتبر ظهور بلد غير صحيح أو محلّل أسماء تابع لمزوّد خدمة الإنترنت لديك الإشارة الفعلية إلى التسرّب.

إضافة Tailscale بجانب VPN sidecar، وأيهما تكون له الأولوية

Tailscale شبكة تراكبية مبنية على WireGuard للوصول إلى أجهزتك، ويشغّلها بعض المستخدمين بجانب VPN مقدّم الخدمة للحفاظ على مسار إداري إلى المنظومة. تعني مشاركة مساحة الأسماء مشاركة قواعد الجدار الناري أيضاً، لذلك يجب أن تكون إعدادات الجدار الناري والتوجيه متوافقة. توضّح وثائق Tailscale الإعداد الافتراضي: تعمل Tailscale كشبكة تراكبية، ولا توجّه إلا حركة المرور بين الأجهزة التي تشغّل Tailscale، ولا تتعامل مع حركة المرور العامة إلى الإنترنت.

لذلك تعتمد الإجابة على إعداد واحد.

• حاوية Tailscale مستقلة بالإعداد الافتراضي: لا ترى مطلقاً حركة المرور الصادرة من التطبيق. يتولى Gluetun كل حركة المرور. تصل عملية داخل حاوية Tailscale إلى التطبيق عبر gluetun:8080 من خلال شبكة Docker مشتركة؛ ويتطلب إتاحة هذا الاتصال لعملاء tailnet إعداد forwarding أو proxy.
• ربط Tailscale بمساحة أسماء gluetun باستخدام network_mode: "service:gluetun": في وضع userspace networking الافتراضي، يكون TS_USERSPACE مفعّلاً، ولا ينشئ tailscaled أي واجهة على الإطلاق، بل يعمل كـSOCKS5 أو HTTP proxy، لذلك لا يمكنه تغيير التوجيه. يواصل Gluetun نقل حركة المرور الصادرة العادية، ما لم يستخدم التطبيق ذلك الـproxy صراحةً.
• الإعداد نفسه مع TS_USERSPACE=false: تحتاج Tailscale إلى جهاز /dev/net/tun وإلى capabilities الخاصة بها، لأن مساحة الأسماء لا توفرهما. ينشئ tailscaled جهاز tunnel، وعادةً يثبت على Linux مسارات IPv4 فردية من نوع /32 للأجهزة النظيرة بدلاً من مسار واحد لـ100.64.0.0/10. لا يؤدي ضبط TS_USERSPACE=false وحده إلى تفعيل المسار المجمّع. ولا يثبت مسارات الشبكات الفرعية للعُقد الأخرى إلا إذا مرّرت --accept-routes عبر TS_EXTRA_ARGS. يعمل TS_ROUTES في الاتجاه المعاكس: فهو يعلن الشبكات الفرعية التي يمكن لهذه الحاوية الوصول إليها لبقية tailnet، وهو المكافئ لـtailscale set --advertise-routes=، ولا يضيف أي مسارات هنا. تظل حركة المرور العامة تخرج عبر gluetun.
• استخدام kernel networking في مساحة أسماء gluetun مع تحديد exit node عبر sudo tailscale set --exit-node=<exit-node-ip>: تثبت Tailscale المسارات الافتراضية في مساحة الأسماء تلك، لكن جدار Gluetun الناري قد يحظر هذا المسار. لا يؤدي تحديد exit node في حاوية مستقلة إلى تغيير مسارات التطبيق، كما أن وضع userspace ينقل فقط حركة المرور المرسلة صراحةً عبر proxy الخاص به. لا تجمع بين مسارات افتراضية متنافسة في مساحة أسماء gluetun. مسار افتراضي واحد، ومالك واحد.

إذا كانت المسارات المُعلنة هي الهدف، وكنت تريد الوصول إلى الشبكة الخاصة بأكملها خلف الخادم بدلاً من الوصول إلى الخادم وحده، فإن تشغيل Tailscale subnet router على VPS يشرح اعتماد المسار، وتمرير IP، وراية جانب العميل التي لا ينجزها TS_ROUTES وحده.

إذا كانت Tailscale موجودة لتوفير URL إداري بدلاً من توفير مسار، فإن tailscale serve وtailscale funnel يضعان HTTPS أمام خدمة HTTP محلية، ولا يفتحها أمام الإنترنت العام إلا funnel. في Tailscale v1.104.5، تقبل reverse proxies الخاصة بها http://gluetun:8080 مباشرةً عندما تتمكن حاوية Tailscale من الوصول إليه عبر شبكة Docker مشتركة. أدرج مخطط http:// لهدف ليس localhost. ويعمل أيضاً اشتراك مساحة أسماء شبكة gluetun واستهداف http://127.0.0.1:8080.

يظهر أحد الآثار الجانبية عند تشغيل Tailscale داخل النفق. ترى أجهزتها النظيرة عنوان مزود VPN، لذلك توقّع أن تنتقل إلى relays بوتيرة أكبر. يعرض tailscale status قيمة relay "..." بجانب الجهاز النظير بدلاً من direct عند حدوث ذلك. يعمل الاتصال، لكنه يكون أبطأ. إذا كانت الشبكة التراكبية هي الشيء الوحيد الذي تحتاج إليه فعلاً، فإن الفرق بين WireGuard العادي وTailscale هو نقطة البداية الأفضل.

ما الذي يتعطل، والرسالة التي ستراها

يرفض Docker إنشاء حاوية التطبيق. يعني Error response from daemon: conflicting options: port publishing and the container type network mode أن كتلة ports: لا تزال موجودة على الخدمة المرتبطة. انقلها إلى gluetun.

يرفض Compose الملف بأكمله. لا يمكن للخدمة ضبط كل من network_mode وnetworks. ضع الشبكات على gluetun.

لا تستطيع حاوية أخرى حل اسم التطبيق. هذا سلوك صحيح في curl: (6) Could not resolve host: qbittorrent، لأن الحاوية المرتبطة لم تنضم إلى أي شبكة ولم تسجّل أي اسم. استخدم gluetun والمنفذ.

لا تبدأ الحاوية المرتبطة الثانية. لا يمكن لعمليتين في مساحة أسماء واحدة ربط المنفذ نفسه، وتبلغ العملية التي تفشل بأن العنوان مستخدم بالفعل. غيّر المنفذ الداخلي للتطبيق، أو شغّل gluetun ثانياً.

لم يعد التطبيق يملك اتصالاً بالشبكة بعد تعديل gluetun. تؤدي إعادة تشغيل gluetun أو إعادة إنشائه إلى قطع الاتصال عن كل ما هو مرتبط به. أعد تشغيل تلك الحاويات.

تُحمّل الصفحات الصغيرة، لكن الصفحات الكبيرة تتوقف. هذه مشكلة MTU (وحدة النقل القصوى). يضيف النفق عبئاً إضافياً، ويسقط أحد مكونات المسار الحزم التي يتجاوز حجمها الحد من دون إرسال خطأ. تحقق من WIREGUARD_MTU، وقيمته الافتراضية في v3.41.3 هي 1320، وخفّضها إذا كان المسار يتطلب حزمًا أصغر. تستخدم صورة التطوير اكتشاف MTU للمسار عند عدم ضبط هذا الإعداد.

لا تصبح Gluetun سليمة أبداً. يحدد فحص بدء التشغيل أول المشتبه بهم: WARN [vpn] restarting VPN because it failed to pass the healthcheck: startup check: dialing: dial tcp4: lookup cloudflare.com: i/o timeout. تحقق مما إذا كانت key قد انتهت صلاحيتها، ثم مما إذا كانت قائمة الخوادم قديمة، ثم مما إذا كان جدار الحماية على المضيف يحظر UDP الصادر.

FAQ

لماذا توقفت المنافذ المنشورة للحاوية عن العمل خلف Gluetun؟

لأنّ network_mode: "service:gluetun" يضع الحاوية داخل مساحة أسماء الشبكة الخاصة بـGluetun، ولكل مساحة أسماء عنوان IP واحد ومجموعة واحدة من المنافذ التي تستمع عليها الخدمات. يظل التطبيق في حالة استماع، لكن يجب أن تكون قاعدة نشر المنفذ في الحاوية التي تملك مساحة الأسماء. انقل قائمة ports: إلى خدمة gluetun. إذا أبقيتها في الخدمة المرتبطة، فلن ينشئها Docker أصلاً: Error response from daemon: conflicting options: port publishing and the container type network mode.

كيف أصل إلى حاوية داخل نفق VPN من حاوية خارجه؟

استخدم اسم خدمة gluetun والمنفذ الذي يستمع عليه التطبيق، مثل gluetun:8080. لا توجد للحاوية المرتبطة شبكة Docker خاصة بها، لذلك لا يُحل اسمها. لا حاجة إلى نشر أي منفذ لحركة المرور بين الحاويات. في الاتجاه الآخر، تصل حاوية داخل مساحة الأسماء إلى حاوية خارجها باستخدام اسم خدمتها، مثل postgres:5432، في Gluetun v3.41 والإصدارات الأحدث. يحتاج العميل الموجود في شبكة فرعية مختلفة، مثل حاسوب محمول على شبكتك المحلية، إلى مسار عودة يسمح به جدار Gluetun الناري والتوجيه؛ أضف تلك الشبكة الفرعية إلى FIREWALL_OUTBOUND_SUBNETS.

هل يعمل Gluetun كمفتاح إيقاف عند انقطاع VPN؟

نعم، عند تفعيل جدار Gluetun الناري. تشارك الحاوية المرتبطة واجهات Gluetun ومساراته، ويحظر الجدار حركة المرور العادية إلى الإنترنت خارج النفق، مع السماح بنقطة نهاية خادم VPN، وحركة مرور Docker المحلية، والاستثناءات المكوّنة. ثم يعيد Gluetun تشغيل VPN داخلياً ويسجّل WARN [vpn] restarting VPN because it failed to pass the healthcheck بدلاً من الخروج، لأن كل حاوية مرتبطة تفقد اتصالها بالشبكة عند إعادة تشغيل gluetun نفسه.

Tailscale وGluetun في الحزمة نفسها: أيهما ينقل حركة المرور الصادرة؟

ينقل Gluetun حركة المرور الصادرة العادية، ما لم ترسلها صراحةً عبر Tailscale. يوجّه Tailscale حركة المرور بين الأجهزة في tailnet تلقائياً، ويترك حركة المرور العامة دون تغيير. في وضع userspace الافتراضي لصورة الحاوية، لا ينشئ Tailscale أي واجهة على الإطلاق، لذلك لا يمكنه التأثير في التوجيه. مع TS_USERSPACE=false، يحصل Linux عادةً على مسارات /32 منفصلة لـIPv4 لكل نظير بدلاً من مسار تجميعي 100.64.0.0/10، إضافةً إلى مسارات الشبكات الفرعية للعُقد الأخرى فقط إذا أضفت --accept-routes عبر TS_EXTRA_ARGS. يعلن TS_ROUTES عن الشبكات الفرعية لهذه الحاوية إلى tailnet، ولا يضيف أي مسارات محلية. يؤدي اختيار عقدة خروج باستخدام sudo tailscale set --exit-node=<exit-node-ip> إلى تثبيت المسارات الافتراضية في مساحة الأسماء التي تستخدم شبكات Tailscale في النواة فقط؛ ولا تغيّر حاوية منفصلة مسارات التطبيق، بينما ينقل وضع userspace حركة المرور المرسلة عبر الوكيل الخاص به فقط. اختر منتجاً واحداً ليتولى المسار الافتراضي بدلاً من تكديس المنتجين.