Docker container VPN uzerinden nasil yonlendirilir?

Docker container'larını bir VPN üzerinden yönlendirdiğinizde portların neden kaybolduğu

Docker container'larını bir VPN üzerinden yönlendirmek için bir container'a tünel bağlantısını verir, ardından diğerlerini network_mode: "service:gluetun" ile onun ağ ad alanına (network namespace) bağlarsınız. Bu bağlama işlemi, kullanıcıları şaşırtan kısımdır. Bağlanan container artık kendi ağına sahip değildir; bu nedenle yayınladığı portlar ve Docker servis ismi de onunla birlikte ortadan kalkar. Portları bunun yerine VPN container'ı üzerinde yayınlayın; diğer container'lar uygulamaya VPN container'ının ismi üzerinden erişecektir.

Bağlanan container üzerinde bir ports: bloğu bırakırsanız, Docker container'ı oluşturmayı tamamen reddeder:

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

Buradaki araç, WireGuard veya OpenVPN üzerinden ticari bir VPN (sanal özel ağ) sağlayıcısına bağlanan ve kendi güvenlik duvarını barındıran bir container olan Gluetun'dur. Ekim 2026 itibarıyla güncel sürüm v3.41.3'tür. Örneklerde WireGuard ile Mullvad kullanılmıştır, bu nedenle sağlayıcınızdan alınmış bir hesaba ve anahtara ihtiyacınız vardır. Tüneli kendi donanımınızda sonlandırmayı tercih ederseniz, kendi WireGuard sunucunuzu bir VPS üzerinde çalıştırmak diğer ucu oluşturmanızı sağlar ve Docker içinde wg-easy bunu bir web arayüzü ile sarmalar.

network_mode: "service:gluetun" gerçekte ne yapar

Her Docker container'ı normalde kendi ağ ad alanına (network namespace) sahiptir: kendi arayüzleri, yönlendirme tablosu, güvenlik duvarı kuralları ve dinleme soketleri. service: modu bu adımı atlar ve container'ı gluetun'ın ad alanı içinde başlatır. Tek bir ad alanı, tek bir IP adresi anlamına gelir ve bu durum altı şeyi değiştirir.

• Uygulamanın kendine ait bir adresi yoktur. Adresi, gluetun'ın adresidir.
• Uygulama hiçbir Docker ağına bağlı değildir, bu nedenle servis adı asla kaydedilmez ve asla çözümlenmez. Diğer container'lar gluetun kullanmalıdır.
• Ad alanı içindeki container'lar birbirine localhost üzerinden ulaşır.
• Aynı ad alanındaki iki container aynı portu dinleyemez. Gluetun belgeleri bu konuda nettir: bunun bir geçici çözümü yoktur.
• Yetenekler (capabilities) bir ad alanına değil, bir container'a aittir. Tünel arayüzünü oluşturduğu için NET_ADMIN ve /dev/net/tun yetenekleri gluetun'dadır. Bağlı olan container bunları devralmaz.
• Compose, bir servisin hem network_mode hem de networks ayarını yaptığı dosyaları reddeder. gluetun'ı ağlarınıza bağlayın, uygulama da onunla birlikte gelir.

gluetun'ı yeniden başlatmak, ona bağlı olan her şeyin bağlantısını keser. Bu belgelenmiş bir davranıştır ve bağlantı koptuğunda gluetun'ın çıkış yapmak yerine container içindeki VPN sürecini yeniden başlatmasının nedeni budur. gluetun'ı kendiniz yeniden başlattığınızda veya yeniden oluşturduğunuzda, ona bağlı olan container'ları da yeniden başlatın.

Çalışan compose dosyası

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 etiketi, v3 serisindeki en yeni kararlı sürümdür. :latest etiketi, geliştirme aşamasındaki master dalının son commit'ini işaret eder; bu nedenle, Salı günü hata ayıklamak istemediğiniz bir makinede :v3 sürümünü sabitleyin.

WEBUI_PORT=8080, yayınlanan port ile eşleşmelidir; çünkü qBittorrent, gluetun'ın namespace'i içinde dinleme yapar ve yayınlama kuralı, ana makine trafiğini oradaki 8080 numaralı porta yönlendirir. Birini değiştirip diğerini değiştirmezseniz port hiçbir yanıt vermez. 127.0.0.1:8080:8080, web arayüzünü ana makinenin loopback adresinde tutar. Yalın bir 8080:8080, tüm arayüzlerde yayın yapar ve kendi güvenlik duvarı kuralını yazar; Docker yayınlanan portlarının ufw'yi doğrudan atlaması bu şekilde gerçekleşir.

Servisi ayağa kaldırın ve ardından şu sırayla kontrol edin:

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

docker compose ps, gluetun'ı healthy ve qbittorrent'i running olarak göstermelidir. Ardından, diğer her şeyin doğruluğunu belirleyen kontrol olan namespace içinden çıkış adresini onaylayın:

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

Bu JSON içindeki ip alanı, VPN sağlayıcınızın adresi olmalıdır. Eğer bu adres sunucunuzun kendi adresi ise, uygulama tünel içinde değildir ve aşağıda anlatılan hiçbir şey belirtildiği gibi çalışmayacaktır.

Anahtarları compose dosyasının dışında tutun

gluetun.env kimlik bilgilerini barındırır ve git deposuna dahil edilmemelidir:

WIREGUARD_PRIVATE_KEY=wOEI9rqqbDwnN8/Bpp22sVz48T71vJ4fYmFWujulwUU=
WIREGUARD_ADDRESSES=10.64.222.21/32

Her iki değer de sağlayıcınızın hesap panelinden oluşturduğunuz bir WireGuard yapılandırma dosyasından gelir. Dosya izinlerini 600 moduna ayarlayın. Bu yöntemin sağladığı avantaj konusunda gerçekçi olun: anahtar deponuzun dışında kalır ancak docker inspect gluetun, Docker soketine erişebilen herkese tüm ortam değişkenlerini açıkça gösterir. Docker Compose'da ortam dosyaları ve gizli veriler bölümü daha güvenli seçenekleri ele almaktadır.

Tünel dışındaki bir container'ın tünel içindekiyle iletişimi

Her iki yön de çalışır ve her biri farklı bir isim kullanır. İki container'ın ortak bir Docker ağına ihtiyacı vardır; bağlı olan container'ın kendi ağı olmadığından bu, gluetun'un ağı anlamına gelir. Docker Compose ağlarının yapısı varsayılanları açıklar.

Dışarıdan içeriye doğru, gluetun'un ismini ve uygulamanın dinlediği portu kullanın. Bir reverse proxy container'ı, qBittorrent web arayüzüne gluetun:8080 üzerinden erişir. Bunun için herhangi bir ports: girdisine gerek yoktur, çünkü container'lar arası trafik Docker ağı üzerinde kalır ve hiçbir zaman host portuna temas etmez.

İçeriden dışarıya doğru, diğer container'ın servis ismini, örneğin postgres:5432 kullanın. Gluetun, v3.41 sürümünden beri kendi namespace'i içerisinden diğer container isimlerini çözümleyebilmektedir; bu nedenle isim çözümleme başarısız olursa bu sürümü veya daha yenisini sabitleyin.

Gluetun'un güvenlik duvarı, kendisine kimin bağlantı açabileceğine karar verir. Gluetun'un kendi Docker ağından gelen trafiğe izin verilir. Farklı bir alt ağdaki bir istemci, yerel ağınızdaki bir dizüstü bilgisayar veya ayrı bir bridge ağındaki bir container, gluetun'un güvenlik duvarı ve yönlendirmesi tarafından izin verilen bir dönüş yoluna ihtiyaç duyar:

FIREWALL_OUTBOUND_SUBNETS=192.168.1.0/24

Belgelenen anlam kesindir: Gluetun'un ve ağ yığınını paylaşan container'ların erişmesine izin verilen, virgülle ayrılmış alt ağlar.

İnternetten gelen gelen bağlantılar ayrı bir sorundur. Bir torrent istemcisinin eşleri VPN tarafından gelir, bu nedenle host üzerinde 6881 portunu yayınlamak onlar için bir işe yaramaz. Sağlayıcınızdan yönlendirilmiş bir porta ihtiyacınız vardır ve bu portun, VPN sunucusu tarafından sağlanan portlara izin veren FIREWALL_VPN_INPUT_PORTS içerisinde listelenmesi gerekir. Bu örnekte kullanılan Mullvad port yönlendirmeyi desteklemediğinden, bu işlem destekleyen bir sağlayıcı gerektirir. Bu, Docker Compose ile oluşturulan medya yığınlarının çoğunda eksik bırakılan parçadır.

Kill switch: Tünel bağlantısı koptuğunda ne olur?

Bu yapı, hata durumlarındaki karmaşıklığı sayesinde güvenliğini sağlar. Bağlı container, Gluetun'un arayüzlerini ve yönlendirme tablosunu paylaşır. Gluetun'un güvenlik duvarı, VPN sunucusu uç noktasına, yerel Docker trafiğine ve yapılandırılmış istisnalara izin verirken, tünel dışındaki standart internet trafiğini engeller. Tünel koptuğunda bağlantının normal arayüze düşmesini engelleyen mekanizma bu güvenlik duvarıdır. İstemci yeniden bağlanırken paketlerin normal arayüzden sızabileceği bir zaman aralığı oluşmaz.

Gluetun kendi bağlantısını sürekli izler. Her dakika HEALTH_ICMP_TARGET_IPS adreslerine (varsayılan olarak 1.1.1.1,8.8.8.8) bir ICMP echo (ping) gönderir. ICMP'ye izin verilmiyorsa, bu küçük kontrol işlemi yerine düz metin UDP DNS sorgusu gerçekleştirilir. Her beş dakikada bir, varsayılan olarak cloudflare.com:443,github.com:443 olan HEALTH_TARGET_ADDRESSES adresine tam bir TCP ve TLS (transport layer security) bağlantısı dener. Bu denemeler başarısız olduğunda, container içindeki VPN servisini yeniden başlatır ve durumu günlüğe kaydeder:

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

Bağlı container'ın günlüklerini bu işleyişi göz önünde bulundurarak inceleyin. Uygulama içindeki connection refused, operation not permitted ve i/o timeout gibi satırlar, tünelin kopmasının birer sonucudur, nedeni değil. Gluetun belgeleri bunu açıkça belirtir; çünkü kullanıcılar genellikle sonucu bir neden sanıp saatlerce yanlış iz sürmektedir.

HEALTH_RESTART_VPN=on varsayılan ayardır ve açık kalmalıdır. Yalnızca belirli bir hata durumunda hata ayıklama yaparken kapatın; çünkü bu ayar kapalıyken kopan bir tünel kendiliğinden tekrar ayağa kalkmaz.

Sıralama: stack'in tünel hazır olmadan başlamasını engelleme

İmaj, bir Docker healthcheck içerir:

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

Bu komut, http://127.0.0.1:9999/ adresindeki çalışan gluetun örneğinin sağlık sunucusunu sorgulayan, kısa ömürlü ikinci bir gluetun kopyası çalıştırır. Çalışan bir tünel 200 OK yanıtını verir. Bağlantısı kopmuş bir tünel ise hata metniyle birlikte 500 Internal server error yanıtını döndürür ve Docker, art arda üç başarısız denemeden sonra container'ı sağlıksız (unhealthy) olarak işaretler.

condition: service_healthy, bu durumu bekleyen yapıdır. Standart depends_on: [gluetun] yalnızca container'ın başlamasını bekler; bu durum el sıkışma tamamlanmadan birkaç saniye önce gerçekleştiği için uygulama ölü bir ağ üzerinde başlar ve genellikle ilk bağlantı denemesinde hata verir. Docker Compose'da sağlık kontrolleri bölümü, sözdizimini ve zamanlama alanlarını detaylandırır.

Bir sınırlama kullanıcıların sıkça karşılaştığı bir durumdur. Compose, bu koşulu stack'i başlattığı anda değerlendirir. Eğer gluetun daha sonra sağlıksız duruma düşerse, uygulamayı durdurmaz veya yeniden başlatmaz. Gluetun'ın kendi içindeki otomatik iyileştirme mekanizması bu durumu karşılar; bu nedenle container yerine VPN sürecini yeniden başlatır.

Kurulumu güvenli kabul etmeden önce DNS sızıntısı kontrolü yapın

DNS (domain name system), doğru yapılandırılmış bir tünelde bile sızıntıya neden olabilen bir bileşendir. Gluetun, kendi çözümleyicisini (resolver) isim alanı (namespace) içinde çalıştırır ve sorguları varsayılan olarak DoT (DNS over TLS) üzerinden Cloudflare'e iletir: DNS_UPSTREAM_RESOLVER_TYPE=dot ve DNS_UPSTREAM_RESOLVERS=cloudflare. Bu ayarları değiştirmeyin; böylece sorgularınız şifrelenir ve tünel üzerinden iletilir.

Yerel bir çözümleyiciye işaret edildiğinde bu yapıyı bozan ayar DNS_UPSTREAM_PLAIN_ADDRESSES ayarıdır. Kullanıcılar, bir alan adı çözülemediğinde ve yönlendiricilerinin veya servis sağlayıcılarının çözümleyicisini kullanmak istediklerinde bu ayara başvururlar. Gluetun belgeleri, Docker köprünüzdeki veya yerel ağınızdaki (LAN) bir çözümleyiciye gönderilen sorguların VPN tüneli dışına sızdığı konusunda uyarıda bulunur. Genel, şifrelenmemiş (plaintext) bir çözümleyici, sorguları tünel üzerinden alsa bile VPN sağlayıcısı bu sorguları okuyabilir ve değiştirebilir. Aynı hatanın WireGuard sürümü için WireGuard tüneli üzerinden çözülmeyen DNS bölümüne bakınız.

Test etmek için gluetun üzerinde SHADOWSOCKS=on ve SHADOWSOCKS_PASSWORD ayarlarını yapın, 8388:8388/tcp ve 8388:8388/udp portlarını dışarıya açın, ardından UDP DNS trafiğini tünellemek üzere yapılandırılmış bir Shadowsocks istemcisi ile bağlanın ve bir DNS sızıntı testi çalıştırın. Sonuçta ev yönlendiriciniz değil, VPN sağlayıcınız veya Cloudflare görünmelidir. Gluetun'un kendi belgeleri, bazı sızıntı testlerinin hatalı sonuçlar verebileceği konusunda uyarıda bulunur; çünkü isim alanı içindeki çözümleyici, nihai yanıtı veren sunucudan ziyade yerel bir önbellekleme aracıdır. Yanlış bir ülke veya kendi ISS'nizin çözümleyicisinin görünmesini gerçek bir sızıntı sinyali olarak kabul edin.

VPN sidecar'ın yanına Tailscale eklemek ve hangisinin öncelikli olduğu

Tailscale, kendi makinelerinize erişmek için WireGuard üzerine inşa edilmiş bir katman ağıdır (overlay network) ve kullanıcılar, yığına (stack) bir yönetici erişim yolu bırakmak için bunu bir VPN sağlayıcısı ile birlikte çalıştırır. Bir namespace paylaşmak, güvenlik duvarı kurallarını da paylaşmak anlamına gelir; bu nedenle ikisinin uyumlu güvenlik duvarı ve yönlendirme ayarlarına sahip olması gerekir. Tailscale belgeleri varsayılan durumu şöyle belirtir: Tailscale bir katman ağı olarak çalışır, yalnızca Tailscale çalıştıran cihazlar arasındaki trafiği yönlendirir ve genel internet trafiğinize müdahale etmez.

Bu nedenle cevap tek bir ayara bağlıdır.

• Kendi container'ı içinde Tailscale, varsayılan yapılandırma: Uygulamanın giden trafiğini asla görmez. Tüm trafiği Gluetun taşır. Tailscale container'ındaki bir süreç, paylaşılan bir Docker ağı üzerinden uygulamaya gluetun:8080 adresinden erişir; bu bağlantıyı tailnet istemcilerine açmak için yönlendirme veya bir proxy gerekir.
• network_mode: "service:gluetun" ile Gluetun'un namespace'ine eklenmiş Tailscale: Varsayılan userspace ağ modunda, TS_USERSPACE açıkken tailscaled hiçbir arayüz oluşturmaz ve SOCKS5 veya HTTP proxy olarak çalışır, bu yüzden yönlendirmeyi değiştiremez. Uygulama bu proxy'yi açıkça kullanmadığı sürece, normal giden trafiği Gluetun taşımaya devam eder.
• Aynı durum, TS_USERSPACE=false ile: Tailscale'in kendi /dev/net/tun cihazına ve yeteneklerine ihtiyacı vardır çünkü bunlar namespace ile birlikte gelmez. Tailscaled bir tünel cihazı oluşturur ve Linux üzerinde normalde 100.64.0.0/10 için tek bir rota yerine bireysel IPv4 peer /32 rotaları kurar. Yalnızca TS_USERSPACE=false ayarını yapmak toplu rotayı etkinleştirmez. Diğer düğümlerin alt ağ rotalarını yalnızca --accept-routes değerini TS_EXTRA_ARGS üzerinden geçirirseniz kurar. TS_ROUTES diğer yönde çalışır: bu container'ın erişebildiği alt ağları tailnet'inizin geri kalanına duyurur, bu tailscale set --advertise-routes= ile eşdeğerdir ve burada herhangi bir rota eklemez. Genel trafik yine Gluetun üzerinden çıkar.
• Bir çıkış düğümü (exit node) seçilmiş şekilde Gluetun'un namespace'inde çekirdek (kernel) ağ iletişimi, sudo tailscale set --exit-node=<exit-node-ip>: Tailscale bu namespace içine varsayılan rotalar kurar ancak Gluetun'un güvenlik duvarı bu yolu engelleyebilir. Ayrı bir container'da çıkış düğümü seçmek uygulamanın rotalarını değiştirmez ve userspace modu yalnızca proxy'si üzerinden açıkça gönderilen trafiği taşır. Gluetun'un namespace'inde birbiriyle yarışan varsayılan rotaları birleştirmeyin. Tek bir varsayılan rota, tek bir sahip.

Eğer amaç duyurulan rotalarsa ve kutunun kendisi yerine kutunun arkasındaki tüm özel ağa ulaşılabilir olmasını istiyorsanız, bir VPS üzerinde Tailscale alt ağ yönlendiricisi çalıştırmak, TS_ROUTES ayarının tek başına eksik bıraktığı rota onayı, IP yönlendirme ve istemci tarafı bayrağı konularını kapsar.

Tailscale orada bir rota yerine size bir yönetici URL'si sağlamak için bulunuyorsa, tailscale serve ve tailscale funnel, yerel bir HTTP servisinin önüne HTTPS koyar ve yalnızca funnel özelliği ile bunu genel internete açar. Tailscale v1.104.5 sürümünde, HTTP ters proxy'leri, Tailscale container'ı paylaşılan bir Docker ağı üzerinden erişebildiğinde http://gluetun:8080 adresini doğrudan kabul eder. Localhost olmayan bir hedef için http:// şemasını dahil edin. Gluetun'un ağ namespace'ini paylaşmak ve http://127.0.0.1:8080 adresini hedeflemek de işe yarar.

Bir yan etki, Tailscale tünel içinde çalıştığında görülür. Eşleri (peers) VPN sağlayıcısının adresini görür, bu nedenle daha sık rölelere (relays) düşmesini bekleyin. Bu gerçekleştiğinde tailscale status, bir eşin yanında direct yerine relay "..." gösterir. Bağlantı çalışır ancak daha yavaştır. Eğer aslında ihtiyacınız olan tek şey katman ağı ise, saf WireGuard ile Tailscale arasındaki fark daha iyi bir başlangıç noktasıdır.

Neler bozulur ve göreceğiniz mesajlar

Docker, uygulama container'ını oluşturmayı reddediyor. Error response from daemon: conflicting options: port publishing and the container type network mode, bağlı servis üzerinde bir ports: bloğunun hala mevcut olduğu anlamına gelir. Bunu gluetun'a taşıyın.

Compose tüm dosyayı reddediyor. Bir servis aynı anda hem network_mode hem de networks ayarını yapamaz. Ağ yapılandırmasını gluetun üzerine alın.

Başka bir container uygulamayı çözümleyemiyor. curl: (6) Could not resolve host: qbittorrent beklenen davranıştır, çünkü bağlı container hiçbir ağa katılmamış ve hiçbir isim kaydetmemiştir. gluetun ve port numarasını kullanın.

İkinci bağlı container başlamıyor. Aynı namespace içindeki iki süreç aynı portu dinleyemez; kaybeden süreç, adresin kullanımda olduğuna dair hata verir. Uygulamanın dahili portunu değiştirin veya ikinci bir gluetun çalıştırın.

gluetun'a müdahale ettikten sonra uygulamanın ağı kesildi. gluetun'u yeniden başlatmak veya yeniden oluşturmak, ona bağlı olan her şeyin bağlantısını koparır. Bu container'ları yeniden başlatın.

Küçük sayfalar yükleniyor ancak büyük olanlar takılıyor. Bu durum MTU (maximum transmission unit) ile ilgilidir. Tünel ek yük getirir ve yol üzerindeki bir cihaz, hata mesajı göndermeden büyük paketleri düşürür. v3.41.3 sürümünde varsayılan değeri 1320 olan WIREGUARD_MTU ayarını kontrol edin; yol daha küçük paketler gerektiriyorsa bu değeri düşürün. Geliştirme imajı, bu ayar belirtilmediğinde path MTU discovery özelliğini kullanır.

gluetun sağlıklı (healthy) duruma geçmiyor. Başlangıç kontrolü ilk şüphelileri belirtir: WARN [vpn] restarting VPN because it failed to pass the healthcheck: startup check: dialing: dial tcp4: lookup cloudflare.com: i/o timeout. Anahtarın süresinin dolup dolmadığını, sunucu listesinin güncel olup olmadığını ve ana makine güvenlik duvarınızın giden UDP trafiğini engelleyip engellemediğini kontrol edin.

FAQ

Konteynerimin yayınlanan portları neden Gluetun arkasında çalışmayı durdurdu?

Çünkü network_mode: "service:gluetun", konteyneri gluetun'un ağ ad alanına (network namespace) yerleştirir ve bir ad alanı tek bir IP adresine ve tek bir dinleme portu kümesine sahiptir. Uygulama dinlemeye devam eder, ancak yayınlama kuralının ad alanına sahip olan konteyner üzerinde tanımlanması gerekir. ports: listesini gluetun servisine taşıyın. Eğer bağlı serviste bırakırsanız, Docker bunu oluşturmayacaktır: Error response from daemon: conflicting options: port publishing and the container type network mode.

VPN tüneli içindeki bir konteynere, dışındaki bir konteynerden nasıl erişirim?

Gluetun'un servis adını ve uygulamanın dinlediği portu kullanın; örneğin gluetun:8080. Bağlı konteynerin kendine ait bir Docker ağı yoktur, bu nedenle kendi adı hiçbir zaman çözümlenmez. Konteynerler arası trafik için herhangi bir port yayınlamaya gerek yoktur. Diğer yönde ise, ad alanı içindeki bir konteyner, dışarıdaki bir konteynere servis adıyla (örneğin postgres:5432) Gluetun v3.41 ve daha yeni sürümlerde erişebilir. LAN üzerindeki bir dizüstü bilgisayar gibi farklı bir alt ağdaki bir istemci, gluetun'un güvenlik duvarı ve yönlendirmesi tarafından izin verilen bir dönüş yoluna ihtiyaç duyar; bu alt ağı FIREWALL_OUTBOUND_SUBNETS kısmına ekleyin.

VPN bağlantısı koptuğunda Gluetun bir kill switch olarak çalışır mı?

Evet, güvenlik duvarı etkinleştirildiğinde çalışır. Bağlı konteyner, Gluetun'un arayüzlerini ve rotalarını paylaşır; güvenlik duvarı, VPN sunucusu uç noktasına, yerel Docker trafiğine ve yapılandırılmış istisnalara izin verirken tünel dışındaki normal internet trafiğini engeller. Gluetun, VPN'i dahili olarak yeniden başlatır ve WARN [vpn] restarting VPN because it failed to pass the healthcheck günlüğünü tutar; kendisi yeniden başladığında tüm bağlı konteynerler ağ bağlantısını kaybedeceği için süreçten çıkış yapmaz.

Aynı stack içinde Tailscale ve Gluetun: giden trafiği hangisi taşır?

Tailscale üzerinden açıkça yönlendirmediğiniz sürece, normal giden trafiği Gluetun taşır. Tailscale varsayılan olarak yalnızca tailnet'inizdeki cihazlar arasındaki trafiği yönlendirir ve genel trafiğe müdahale etmez. Konteyner imajının varsayılan userspace modunda hiçbir arayüz oluşturulmaz, bu nedenle yönlendirmeyi etkileyemez. TS_USERSPACE=false ile Linux normalde toplu bir 100.64.0.0/10 rotası yerine bireysel IPv4 peer /32 rotaları alır; ayrıca diğer düğümlerin alt ağ rotaları yalnızca --accept-routes üzerinden TS_EXTRA_ARGS eklerseniz geçerli olur. TS_ROUTES, bu konteynerin alt ağlarını tailnet'inize duyurur ve yerel rota eklemez. sudo tailscale set --exit-node=<exit-node-ip> ile bir çıkış düğümü (exit node) seçmek, yalnızca Tailscale'in çekirdek ağını (kernel networking) kullanan ad alanında varsayılan rotaları kurar; ayrı bir konteyner uygulamanın rotalarını değiştirmez ve userspace modu yalnızca proxy üzerinden gönderilen trafiği taşır. İkisini üst üste bindirmek yerine varsayılan rotaya sahip olacak tek bir ürün seçin.