آموزش هدایت ترافیک کانتینرهای Docker از طریق VPN

چرا هنگام هدایت کانتینرهای Docker از طریق VPN، پورت‌ها ناپدید می‌شوند

برای هدایت کانتینرهای Docker از طریق یک VPN، باید تونل را به یک کانتینر اختصاص دهید و سپس بقیه کانتینرها را با استفاده از network_mode: "service:gluetun" به فضای نام شبکه (network namespace) آن متصل کنید. این اتصال همان بخشی است که باعث تعجب کاربران می‌شود. کانتینر متصل‌شده دیگر شبکه اختصاصی خود را ندارد، بنابراین پورت‌های منتشرشده (published ports) و نام سرویس Docker آن نیز همراه با شبکه اختصاصی‌اش حذف می‌شوند. پورت‌ها را روی کانتینر VPN منتشر کنید تا سایر کانتینرها بتوانند از طریق نام کانتینر VPN به برنامه دسترسی پیدا کنند.

اگر یک بلوک ports: روی کانتینر متصل‌شده باقی بگذارید، Docker از ایجاد آن کانتینر به‌طور کامل خودداری می‌کند:

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

ابزار مورد استفاده در اینجا Gluetun است؛ کانتینری که از طریق WireGuard یا OpenVPN به یک ارائه‌دهنده VPN تجاری متصل می‌شود و فایروال اختصاصی خود را دارد. نسخه v3.41.3 تا اوت 2026 نسخه جاری است. مثال‌ها از Mullvad با WireGuard استفاده می‌کنند، بنابراین به یک حساب کاربری و یک کلید از ارائه‌دهنده خود نیاز دارید. اگر ترجیح می‌دهید تونل را روی سخت‌افزاری که مالک آن هستید خاتمه دهید، راه‌اندازی سرور WireGuard شخصی روی یک VPS سمت دیگر اتصال را می‌سازد و wg-easy در Docker آن را در یک رابط کاربری وب بسته‌بندی می‌کند.

عملکرد واقعی network_mode: "service:gluetun"

هر container در Docker به‌طور معمول یک network namespace اختصاصی دریافت می‌کند: اینترفیس‌ها، جدول مسیریابی، قوانین فایروال و سوکت‌های listening مخصوص به خود. حالت service: از این مرحله صرف‌نظر کرده و container را درون namespace مربوط به gluetun اجرا می‌کند. یک namespace واحد به معنای یک آدرس IP واحد است و این موضوع 6 مورد را تغییر می‌دهد:

• برنامه هیچ آدرس مستقلی ندارد. آدرس آن همان آدرس gluetun است.
• برنامه به هیچ شبکه Docker متصل نیست، بنابراین نام سرویس آن هرگز ثبت نشده و resolve نمی‌شود. سایر containerها باید از gluetun استفاده کنند.
• containerهای درون یک namespace از طریق localhost به یکدیگر دسترسی دارند.
• دو container در یک namespace نمی‌توانند روی یک پورت مشابه گوش دهند. مستندات Gluetun در این باره صریح است: هیچ راه حلی برای این محدودیت وجود ندارد.
• قابلیت‌ها (Capabilities) متعلق به یک container هستند، نه یک namespace. ابزار Gluetun دارای NET_ADMIN و /dev/net/tun است زیرا اینترفیس تونل را ایجاد می‌کند. container متصل‌شده این قابلیت‌ها را به ارث نمی‌برد.
• ابزار Compose هر فایلی را که در آن یک سرویس همزمان network_mode و networks را تنظیم کرده باشد، رد می‌کند. gluetun را به شبکه‌های خود متصل کنید تا برنامه همراه با آن عمل کند.

راه‌اندازی مجدد (Restart) gluetun باعث قطع اتصال تمام مواردی می‌شود که به آن متصل هستند. این یک رفتار مستندشده است و به همین دلیل است که gluetun به‌جای خروج در هنگام شکست اتصال، فرآیند VPN را درون container مجدداً راه‌اندازی می‌کند. پس از اینکه خودتان gluetun را restart یا recreate کردید، containerهای متصل به آن را نیز restart کنید.

فایل 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 اشاره دارد که لبه توسعه (development edge) محسوب می‌شود؛ بنابراین در ماشینی که نمی‌خواهید سه‌شنبه‌ها درگیر عیب‌یابی آن باشید، از :v3 استفاده نکنید.

مقدار WEBUI_PORT=8080 باید با پورت منتشرشده مطابقت داشته باشد، زیرا qBittorrent در داخل namespace مربوط به gluetun متصل (bind) می‌شود و قانون انتشار (publish rule)، ترافیک میزبان را به پورت 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 نشان دهد. سپس آدرس خروجی را از داخل namespace تأیید کنید؛ این همان بررسی نهایی است که وضعیت سایر موارد را تعیین می‌کند:

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 دسترسی داشته باشد، نمایش می‌دهد. فایل‌های محیطی و secrets در Docker Compose گزینه‌های امن‌تر را بررسی می‌کند.

نحوه برقراری ارتباط بین یک کانتینر خارج از تونل و یک کانتینر داخل آن

هر دو جهت ارتباط کار می‌کنند و هر کدام از نام متفاوتی استفاده می‌کنند. این دو کانتینر به یک شبکه Docker مشترک نیاز دارند؛ یعنی شبکه gluetun، زیرا کانتینر متصل‌شده به آن، شبکه مستقلی ندارد. بخش نحوه سیم‌کشی شبکه‌های Docker Compose تنظیمات پیش‌فرض را پوشش می‌دهد.

برای ارتباط از خارج به داخل، از نام gluetun و پورتی که برنامه روی آن گوش می‌دهد استفاده کنید. یک کانتینر reverse proxy به رابط وب qBittorrent در gluetun:8080 دسترسی پیدا می‌کند. برای این کار نیازی به ورودی ports: نیست، زیرا ترافیک بین کانتینرها در شبکه Docker باقی می‌ماند و هرگز با پورت میزبان (host) تماس پیدا نمی‌کند.

برای ارتباط از داخل به خارج، از نام سرویس کانتینر دیگر، مثلاً postgres:5432، استفاده کنید. از نسخه v3.41 به بعد، gluetun نام سایر کانتینرها را از داخل فضای نام (namespace) خود شناسایی می‌کند؛ بنابراین اگر نامی شناسایی نشد، از این نسخه یا نسخه‌های جدیدتر استفاده کنید.

فایروال gluetun تعیین می‌کند چه کسی اجازه برقراری اتصال با آن را دارد. ترافیک شبکه Docker خودِ gluetun مجاز است. اتصالات از یک زیرشبکه (subnet) متفاوت، مانند لپ‌تاپی در LAN شما یا کانتینری در یک شبکه bridge جداگانه، مسدود می‌شوند مگر اینکه آن زیرشبکه را مشخص کنید:

FIREWALL_OUTBOUND_SUBNETS=192.168.1.0/24

معنای مستندات دقیق است: زیرشبکه‌های جداشده با کاما که gluetun و کانتینرهایی که از پشته شبکه آن استفاده می‌کنند، اجازه دسترسی به آن‌ها را دارند.

اتصالات ورودی از اینترنت مسئله متفاوتی هستند. همتایان (peers) یک کلاینت تورنت از سمت VPN می‌آیند، بنابراین انتشار پورت 6881 روی میزبان برای آن‌ها تأثیری ندارد. شما به یک پورت فوروارد شده از طرف ارائه‌دهنده خود نیاز دارید و آن پورت باید در FIREWALL_VPN_INPUT_PORTS لیست شود تا اجازه عبور پورت‌ها از سمت سرور VPN صادر گردد. این همان بخشی است که اکثر پشته‌های رسانه‌ای ساخته‌شده با Docker Compose آن را ناقص باقی می‌گذارند.

کلید قطع اضطراری (kill switch): هنگام قطع تونل چه اتفاقی می‌افتد

این الگو پیچیدگی خود را در زمان بروز خطا نشان می‌دهد. کانتینر متصل، مسیر دومی ندارد. تنها راه خروج آن از ماشین، فضای نامی (namespace) است که با آن به اشتراک گذاشته شده است؛ بنابراین وقتی تونل قطع می‌شود، هیچ مسیر جایگزینی برای ترافیک وجود ندارد. فایروال Gluetun همین قانون را از سمت دیگر اعمال می‌کند: ترافیک خروجی باید از طریق تونل یا به سمت endpoint سرور VPN عبور کند و هر چیز دیگری مسدود (drop) می‌شود. هیچ بازهٔ زمانی وجود ندارد که در آن بسته‌ها در حین اتصال مجدد کلاینت، از رابط شبکهٔ معمولی (plain interface) نشت کنند.

Gluetun اتصال خود را پایش می‌کند. هر دقیقه یک ICMP echo (یک ping) به آدرس‌های موجود در HEALTH_ICMP_TARGET_IPS ارسال می‌کند که به‌صورت پیش‌فرض 1.1.1.1,8.8.8.8 هستند. هر پنج دقیقه، یک اتصال کامل 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 مقدار پیش‌فرض است و باید فعال بماند. آن را فقط زمانی غیرفعال کنید که در حال عیب‌یابی یک خطای خاص هستید، زیرا با غیرفعال بودن آن، تونل قطع‌شده به همان حالت باقی می‌ماند.

ترتیب‌بندی: جلوگیری از شروع stack پیش از برقراری تونل

این ایمیج دارای یک healthcheck در Docker است:

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

این دستور یک کپی کوتاه‌مدت از gluetun اجرا می‌کند که سرور سلامتِ نمونهٔ در حال اجرا را در http://127.0.0.1:9999/ پرس‌وجو می‌کند. یک تونل فعال پاسخ 200 OK را برمی‌گرداند. تونل قطع‌شده پاسخ 500 Internal server error را به همراه یک رشته خطا برمی‌گرداند و کانتینر پس از یک بار شکست، به عنوان ناسالم (unhealthy) علامت‌گذاری می‌شود.

condition: service_healthy همان چیزی است که منتظر این وضعیت می‌ماند. دستور سادهٔ depends_on: [gluetun] فقط منتظر شروع کانتینر می‌ماند که چندین ثانیه پیش از تکمیل handshake رخ می‌دهد؛ بنابراین برنامه در یک شبکهٔ غیرفعال شروع به کار می‌کند و اغلب در اولین تلاش برای اتصال، متوقف می‌شود. بررسی‌های سلامت در Docker Compose نحو و فیلدهای زمانی مربوطه را توضیح می‌دهد.

یک محدودیت وجود دارد که کاربران را دچار مشکل می‌کند. Compose این شرط را فقط یک بار، هنگام ایجاد کانتینر ارزیابی می‌کند. اگر وضعیت gluetun بعداً به ناسالم تغییر کند، برنامه را متوقف یا ری‌استارت نمی‌کند. قابلیت خودترمیمی (auto-healing) داخلی gluetun این مورد را پوشش می‌دهد؛ به همین دلیل است که این ابزار به‌جای ری‌استارت کردن کانتینر، فرآیند VPN را مجدداً راه‌اندازی می‌کند.

بررسی نشت DNS پیش از اعتماد به تنظیمات

DNS (سیستم نام دامنه) نشتی است که حتی پس از برقراری صحیح تونل نیز باقی می‌ماند. Gluetun به صورت پیش‌فرض resolver اختصاصی خود را درون namespace اجرا کرده و پرس‌وجوها را از طریق DoT (DNS over TLS) به Cloudflare ارسال می‌کند: DNS_UPSTREAM_RESOLVER_TYPE=dot و DNS_UPSTREAM_RESOLVERS=cloudflare. این دو مورد را تغییر ندهید تا جستجوهای شما رمزنگاری شده و از طریق تونل منتقل شوند.

تنظیمی که باعث اختلال در این روند می‌شود DNS_UPSTREAM_PLAIN_ADDRESSES است. کاربران زمانی به سراغ این گزینه می‌روند که نامی resolve نمی‌شود و می‌خواهند روتر یا resolver ارائه‌دهندهٔ اینترنت‌شان پاسخگو باشد. مستندات Gluetun هزینهٔ این کار را به‌وضوح بیان می‌کند: تمام ترافیک DNS از تونل VPN عبور نکرده و از آن نشت می‌کند. ترافیک شما خصوصی باقی می‌ماند، اما لیست نام‌های میزبان (hostname) خیر. نسخهٔ مشابه این اشتباه در WireGuard در DNS که از طریق تونل WireGuard پاسخ نمی‌دهد پوشش داده شده است.

برای تست این موضوع، HTTPPROXY=on را در gluetun تنظیم کرده و 8888:8888/tcp را منتشر کنید، سپس مرورگر خود را به آن پروکسی متصل کرده و یک تست نشت DNS را بارگذاری کنید. نتیجه باید نام ارائه‌دهندهٔ شما یا Cloudflare را نشان دهد، نه روتر خانگی‌تان. مستندات خودِ Gluetun هشدار می‌دهد که برخی تست‌های نشت نتایج عجیبی گزارش می‌کنند، زیرا resolver موجود در namespace یک واسط کش محلی است و نه سروری که در نهایت پاسخ می‌دهد. مشاهدهٔ کشوری اشتباه یا resolver متعلق به ISP خودتان را به عنوان نشانهٔ واقعی نشت در نظر بگیرید.

افزودن Tailscale در کنار sidecar مربوط به VPN و تعیین اولویت

Tailscale یک شبکه overlay مبتنی بر WireGuard برای دسترسی به ماشین‌های شخصی است و کاربران آن را در کنار VPNهای ارائه‌دهنده سرویس اجرا می‌کنند تا یک مسیر مدیریتی به stack خود داشته باشند. این دو به دلیلی که درک آن اهمیت دارد، به‌ندرت با هم تداخل پیدا می‌کنند. مستندات Tailscale وضعیت پیش‌فرض را این‌گونه بیان می‌کند: این ابزار به‌عنوان یک شبکه overlay عمل کرده، ترافیک را فقط بین دستگاه‌هایی که Tailscale روی آن‌ها اجرا می‌شود مسیریابی می‌کند و به ترافیک اینترنت عمومی شما دست نمی‌زند.

بنابراین پاسخ به یک تنظیم خاص بستگی دارد.

• Tailscale در container اختصاصی خود با پیکربندی پیش‌فرض: این حالت هرگز ترافیک خروجی برنامه را نمی‌بیند. Gluetun تمام ترافیک را حمل می‌کند. Tailscale دقیقاً مانند هر container خارجی دیگر، از طریق gluetun:8080 به برنامه دسترسی پیدا می‌کند.
• Tailscale متصل به namespace مربوط به gluetun با network_mode: "service:gluetun": این حالت به cap_add اختصاصی از net_admin و net_raw نیاز دارد، زیرا قابلیت‌ها (capabilities) همراه با namespace منتقل نمی‌شوند. در حالت پیش‌فرض شبکه userspace، زمانی که TS_USERSPACE فعال است، tailscaled هیچ رابطی (interface) ایجاد نمی‌کند و به‌عنوان یک SOCKS5 یا HTTP proxy عمل می‌کند، بنابراین نمی‌تواند مسیریابی را تغییر دهد. Gluetun همچنان تمام ترافیک را حمل می‌کند.
• همان حالت با TS_USERSPACE=false: ابزار tailscaled یک دستگاه تونل ایجاد کرده و مسیرها را نصب می‌کند، اما فقط برای محدوده tailnet یعنی 100.64.0.0/10 به اضافه هر subnet route که با TS_ROUTES معرفی کرده باشید. ترافیک عمومی همچنان از طریق gluetun خارج می‌شود.
• هر یک از موارد بالا با انتخاب یک exit node یعنی sudo tailscale set --exit-node=<exit-node-ip>: در این صورت Tailscale مسیر پیش‌فرض (default route) را تصاحب کرده و اولویت پیدا می‌کند. این حالت را با gluetun ترکیب نکنید. هر سیستم فقط یک مسیر پیش‌فرض و یک مالک دارد.

یک اثر جانبی زمانی قابل مشاهده است که Tailscale داخل تونل اجرا شود. همتایان (peers) آن، آدرس ارائه‌دهنده VPN را می‌بینند، بنابراین انتظار داشته باشید که اتصال بیشتر به سمت relayها سوق پیدا کند. وقتی این اتفاق می‌افتد، tailscale status به جای direct، عبارت relay "..." را در کنار یک peer نمایش می‌دهد. اتصال برقرار است اما سرعت آن کمتر خواهد بود. اگر شبکه overlay تنها چیزی است که واقعاً به آن نیاز دارید، تفاوت بین WireGuard ساده و Tailscale نقطه شروع بهتری است.

چه چیزی دچار اختلال می‌شود و چه پیامی مشاهده خواهید کرد

Docker از ایجاد container برنامه خودداری می‌کند. خطای Error response from daemon: conflicting options: port publishing and the container type network mode به این معناست که یک بلوک ports: همچنان روی سرویس متصل باقی مانده است. آن را به gluetun منتقل کنید.

Compose کل فایل را رد می‌کند. یک سرویس نمی‌تواند همزمان network_mode و networks را تنظیم کند. تنظیمات شبکه را روی gluetun قرار دهید.

یک container دیگر نمی‌تواند برنامه را resolve کند. رفتار curl: (6) Could not resolve host: qbittorrent صحیح است، زیرا container متصل‌شده به هیچ شبکه‌ای ملحق نشده و نامی ثبت نکرده است. از gluetun و پورت مربوطه استفاده کنید.

دومین container متصل‌شده شروع به کار نمی‌کند. دو پردازش در یک namespace نمی‌توانند یک پورت مشابه را bind کنند و پردازشی که شکست می‌خورد، گزارش می‌دهد که آدرس در حال استفاده است. پورت داخلی برنامه را تغییر دهید یا یک gluetun دوم اجرا کنید.

پس از دستکاری gluetun، برنامه شبکه ندارد. راه‌اندازی مجدد یا ایجاد دوباره gluetun، اتصال تمام موارد متصل به آن را قطع می‌کند. آن containerها را restart کنید.

صفحات کوچک بارگذاری می‌شوند اما صفحات بزرگ متوقف می‌مانند. این مشکل مربوط به MTU (حداکثر واحد انتقال) است. تونل سربار ایجاد می‌کند و بخشی از مسیر، بسته‌های بیش از حد بزرگ را بدون ارسال پیام خطا حذف می‌کند. مقدار WIREGUARD_MTU را کاهش دهید، 1400 را امتحان کنید و سپس به سراغ 1320 بروید.

وضعیت gluetun هرگز healthy نمی‌شود. بررسی اولیه هنگام شروع کار، مظنونین اصلی را نام می‌برد: WARN [vpn] restarting VPN because it failed to pass the healthcheck: startup check: dialing: dial tcp4: lookup cloudflare.com: i/o timeout. بررسی کنید که آیا کلید منقضی شده است یا خیر، سپس بررسی کنید که آیا لیست سرورها قدیمی است و در نهایت چک کنید که آیا فایروال میزبان شما ترافیک خروجی UDP را مسدود می‌کند یا خیر.

FAQ

چرا پورت‌های منتشرشده کانتینر من پس از قرارگیری پشت Gluetun از کار افتادند؟

زیرا network_mode: "service:gluetun" کانتینر را درون فضای نام شبکه (network namespace) مربوط به gluetun قرار می‌دهد و هر فضای نام تنها یک آدرس IP و یک مجموعه پورت شنونده دارد. برنامه همچنان به گوش دادن ادامه می‌دهد، اما قانون انتشار پورت (publish rule) باید روی کانتینری تعریف شود که مالک فضای نام است. لیست ports: را به سرویس gluetun منتقل کنید. اگر آن را روی سرویس متصل (attached service) باقی بگذارید، Docker حتی آن را ایجاد نخواهد کرد: Error response from daemon: conflicting options: port publishing and the container type network mode.

چگونه از یک کانتینر خارج از تونل VPN به کانتینری درون آن دسترسی پیدا کنم؟

از نام سرویس gluetun و پورتی که برنامه روی آن گوش می‌دهد استفاده کنید، برای مثال gluetun:8080. کانتینر متصل هیچ شبکه Docker اختصاصی ندارد، بنابراین نام خودش هرگز resolve نمی‌شود. برای ترافیک بین کانتینری نیازی به انتشار پورت نیست. در جهت معکوس، کانتینری که درون فضای نام است، در نسخه Gluetun v3.41 و جدیدتر، با استفاده از نام سرویس به کانتینر بیرونی دسترسی پیدا می‌کند، مانند postgres:5432. ترافیک کلاینتی که در زیرشبکه (subnet) متفاوتی است، مانند لپ‌تاپ در شبکه LAN شما، توسط فایروال gluetun مسدود می‌شود مگر اینکه آن زیرشبکه را به FIREWALL_OUTBOUND_SUBNETS اضافه کنید.

آیا Gluetun هنگام قطع شدن VPN به عنوان kill switch عمل می‌کند؟

بله، و به دو دلیل همزمان. کانتینر متصل هیچ مسیری (route) به جز مسیر موجود در فضای نام مشترک ندارد، بنابراین با قطع شدن تونل، هیچ راهی برای خروج از ماشین برای آن باقی نمی‌ماند. فایروال Gluetun نیز ترافیک خروجی را تنها از طریق تونل و به سمت endpoint سرور VPN مجاز می‌داند. Gluetun سپس VPN را به‌صورت داخلی restart می‌کند و پیام WARN [vpn] restarting VPN because it failed to pass the healthcheck را در لاگ ثبت می‌کند، به جای اینکه کلاً خارج شود؛ زیرا با restart شدن خودِ gluetun، تمام کانتینرهای متصل شبکه خود را از دست می‌دهند.

Tailscale و Gluetun در یک stack: کدام‌یک ترافیک خروجی را حمل می‌کند؟

Gluetun، در تمام پیکربندی‌ها به جز یک مورد. Tailscale به‌صورت پیش‌فرض فقط ترافیک بین دستگاه‌ها در tailnet شما را مسیریابی می‌کند و ترافیک عمومی را تغییر نمی‌دهد. در حالت پیش‌فرض userspace این ایمیج کانتینری، هیچ رابطی (interface) ایجاد نمی‌شود، بنابراین نمی‌تواند بر مسیریابی تأثیر بگذارد. با TS_USERSPACE=false، این ابزار فقط مسیرهایی برای 100.64.0.0/10 و زیرشبکه‌های تبلیغ‌شده (advertised subnets) شما نصب می‌کند. استثنا، استفاده از exit node است: sudo tailscale set --exit-node=<exit-node-ip> باعث می‌شود Tailscale به مسیر پیش‌فرض تبدیل شود و در نتیجه اولویت پیدا کند. به جای ترکیب هر دو، یکی از این محصولات را برای مدیریت مسیر پیش‌فرض انتخاب کنید.