Docker-Container über Gluetun-VPN routen

Warum Ports verschwinden, wenn Sie Docker-Container über ein VPN leiten

Um Docker-Container über ein VPN zu leiten, geben Sie einem Container den Tunnel und verbinden die anderen Container mit network_mode: "service:gluetun" mit seinem Netzwerk-Namespace. Diese Verbindung ist der Teil, der viele Nutzer überrascht. Der verbundene Container hat dann kein eigenes Netzwerk mehr. Seine veröffentlichten Ports und sein Docker-Dienstname entfallen dadurch ebenfalls. Veröffentlichen Sie die Ports stattdessen am VPN-Container. Andere Container erreichen die Anwendung dann über den Namen des VPN-Containers.

Wenn Sie am verbundenen Container einen ports:-Block belassen, verweigert Docker die Erstellung vollständig:

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

Das verwendete Tool ist Gluetun. Dabei handelt es sich um einen Container, der über WireGuard oder OpenVPN eine Verbindung zu einem kommerziellen VPN-Anbieter herstellt und eine eigene Firewall mitbringt. Release v3.41.3 ist im Oktober 2026 aktuell. Die Beispiele verwenden Mullvad mit WireGuard. Sie benötigen daher ein Konto und einen Schlüssel Ihres Anbieters. Wenn Sie den Tunnel lieber auf eigener Hardware terminieren möchten, erstellt einen eigenen WireGuard-Server auf einem VPS die Gegenstelle. wg-easy in Docker stellt dafür eine Weboberfläche bereit.

Was network_mode: "service:gluetun" tatsächlich macht

Ein Docker-Container erhält normalerweise einen eigenen Netzwerk-Namespace: eigene Schnittstellen, Routing-Tabelle, Firewall-Regeln und Listening-Sockets. Der Modus service: überspringt diesen Schritt und startet den Container im Namespace von gluetun. Ein Namespace bedeutet eine IP-Adresse. Dadurch ändern sich sechs Dinge.

• Die Anwendung hat keine eigene Adresse. Ihre Adresse ist die Adresse von gluetun.
• Die Anwendung ist mit keinem Docker-Netzwerk verbunden. Ihr Servicename wird daher nie registriert und nie aufgelöst. Andere Container müssen gluetun verwenden.
• Container innerhalb des Namespace erreichen einander über localhost.
• Zwei Container in einem Namespace können nicht am selben Port lauschen. Die Gluetun-Dokumentation formuliert es eindeutig: Es gibt keine Umgehung.
• Capabilities gehören zu einem Container, nicht zu einem Namespace. Gluetun besitzt NET_ADMIN und /dev/net/tun, weil es die Tunnel-Schnittstelle erstellt. Der verbundene Container erbt diese Capabilities nicht.
• Compose lehnt jede Datei ab, in der ein Dienst gleichzeitig network_mode und networks setzt. Verbinden Sie gluetun mit Ihren Netzwerken. Die Anwendung nutzt diese Verbindung mit.

Ein Neustart von gluetun trennt alles, was daran angeschlossen ist. Dieses Verhalten ist dokumentiert. Deshalb startet gluetun den VPN-Prozess innerhalb des Containers neu, anstatt den Container bei einem Verbindungsfehler zu beenden. Nachdem Sie gluetun selbst neu gestartet oder neu erstellt haben, starten Sie die daran angeschlossenen Container neu.

Die funktionierende Compose-Datei

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

Der Tag :v3 ist das neueste stabile Release der v3-Serie. Der Tag :latest verweist auf den letzten Commit des master-Branches, also auf den Entwicklungsstand. Verwenden Sie daher :v3 auf einem Rechner, auf dem Sie nicht unerwartet Fehler suchen möchten.

WEBUI_PORT=8080 muss dem veröffentlichten Port entsprechen, weil qBittorrent innerhalb des Netzwerk-Namespace von gluetun gebunden wird und die Publish-Regel den Host-Datenverkehr dort an Port 8080 weiterleitet. Wenn Sie eine der beiden Zahlen ändern, antwortet der Port nicht. 127.0.0.1:8080:8080 hält die Weboberfläche an der Loopback-Adresse des Hosts. Ein einfaches 8080:8080 veröffentlicht den Port auf allen Schnittstellen und legt eine eigene Firewall-Regel an. Dadurch können veröffentlichte Docker-Ports direkt an ufw vorbeigehen.

Starten Sie die Container und prüfen Sie sie anschließend in dieser Reihenfolge:

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

docker compose ps sollte gluetun als healthy und qbittorrent als running anzeigen. Prüfen Sie anschließend die externe IP-Adresse innerhalb des Namespace. Diese Prüfung entscheidet über alles Weitere:

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

Das Feld ip in dieser JSON-Antwort sollte die Adresse Ihres VPN-Anbieters enthalten. Wenn dort die eigene Adresse Ihres Servers steht, befindet sich die Anwendung nicht im Tunnel. Dann funktioniert nichts im weiteren Verlauf wie beschrieben.

Halten Sie die Schlüssel aus der Compose-Datei heraus

gluetun.env enthält die Zugangsdaten und bleibt außerhalb von Git:

WIREGUARD_PRIVATE_KEY=wOEI9rqqbDwnN8/Bpp22sVz48T71vJ4fYmFWujulwUU=
WIREGUARD_ADDRESSES=10.64.222.21/32

Beide Werte stammen aus einer WireGuard-Konfigurationsdatei, die Sie im Kontobereich Ihres Providers erzeugen. Setzen Sie die Dateiberechtigungen auf 600. Machen Sie sich klar, was dadurch erreicht wird: Der Schlüssel bleibt aus Ihrem Repository heraus, aber docker inspect gluetun gibt weiterhin jede Umgebungsvariable für alle aus, die Zugriff auf den Docker-Socket haben. Umgebungsdateien und Secrets in Docker Compose beschreibt die besseren Optionen.

Wie ein Container außerhalb des Tunnels mit einem Container innerhalb des Tunnels kommuniziert

Beide Richtungen funktionieren. Für jede Richtung wird ein anderer Name verwendet. Die beiden Container benötigen ein gemeinsames Docker-Netzwerk. Das ist das Netzwerk von gluetun, weil der angehängte Container kein eigenes Netzwerk besitzt. Aufbau von Docker-Compose-Netzwerken erläutert die Standardeinstellungen.

Für Verbindungen von außen nach innen verwenden Sie den Namen von gluetun und den Port, auf dem die Anwendung lauscht. Ein Reverse-Proxy-Container erreicht die Weboberfläche von qBittorrent unter gluetun:8080. Dafür ist kein Eintrag ports: erforderlich, weil der Container-zu-Container-Verkehr im Docker-Netzwerk bleibt und keinen Host-Port verwendet.

Für Verbindungen von innen nach außen verwenden Sie den Servicenamen des anderen Containers, zum Beispiel postgres:5432. Gluetun kann seit v3.41 die Namen anderer Container innerhalb seines Netzwerk-Namespace auflösen. Verwenden Sie daher diese Version oder eine neuere, wenn sich ein Name nicht auflösen lässt.

Die Firewall von gluetun entscheidet, wer eine Verbindung zu gluetun öffnen darf. Datenverkehr aus dem eigenen Docker-Netzwerk von gluetun ist erlaubt. Für einen Client in einem anderen Subnetz, einen Laptop in Ihrem LAN oder einen Container in einem separaten Bridge-Netzwerk müssen die Firewall und das Routing von gluetun einen Rückweg erlauben:

FIREWALL_OUTBOUND_SUBNETS=192.168.1.0/24

Die dokumentierte Bedeutung ist eindeutig: durch Kommas getrennte Subnetze, auf die gluetun und die Container mit gemeinsamem Netzwerk-Stack zugreifen dürfen.

Eingehende Verbindungen aus dem Internet sind ein separates Problem. Die Peers eines Torrent-Clients erreichen ihn über die VPN-Seite. Daher hat das Veröffentlichen von Port 6881 auf dem Host keine Wirkung. Sie benötigen einen weitergeleiteten Port von Ihrem Provider und müssen diesen Port in FIREWALL_VPN_INPUT_PORTS angeben. Dadurch werden Ports von der Seite des VPN-Servers erlaubt. Mullvad, das in diesem Beispiel verwendet wird, unterstützt keine Portweiterleitung. Sie benötigen daher einen Provider, der diese Funktion unterstützt. Dieser Teil bleibt bei den meisten mit Docker Compose erstellten Media-Stacks fehlerhaft.

Der Notausschalter: Was passiert, wenn der Tunnel abbricht

Dieses Muster rechtfertigt seine Komplexität im Fehlerfall. Der angebundene Container verwendet die Schnittstellen und die Routing-Tabelle von Gluetun gemeinsam. Die Firewall von Gluetun blockiert normalen Internetverkehr außerhalb des Tunnels. Sie erlaubt jedoch den VPN-Server-Endpunkt, lokalen Docker-Verkehr und konfigurierte Ausnahmen. Diese Firewall verhindert, dass bei einem Tunnelabbruch auf die normale Schnittstelle zurückgefallen wird. Es gibt kein Zeitfenster, in dem Pakete während der erneuten Verbindung eines Clients über die normale Schnittstelle nach außen gelangen.

Gluetun überwacht seine eigene Verbindung. Jede Minute sendet es ein ICMP Echo (einen Ping) an die Adressen in HEALTH_ICMP_TARGET_IPS, die standardmäßig auf 1.1.1.1,8.8.8.8 gesetzt sind. Wenn ICMP nicht zulässig ist, verwendet diese kurze Prüfung stattdessen eine unverschlüsselte UDP-DNS-Abfrage. Alle fünf Minuten stellt Gluetun eine vollständige TCP- und TLS-Verbindung (Transport Layer Security) zu HEALTH_TARGET_ADDRESSES her, standardmäßig zu cloudflare.com:443,github.com:443. Wenn diese Verbindungen fehlschlagen, startet es das VPN im Container neu und schreibt dies ins Log:

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

Lesen Sie die Logs des angebundenen Containers mit diesem Ablauf im Hinterkopf. Zeilen wie connection refused, operation not permitted und i/o timeout innerhalb der Anwendung sind Folgen eines ausgefallenen Tunnels und keine Ursachen. Die Gluetun-Dokumentation weist ausdrücklich darauf hin, weil Benutzer die Folge melden und stundenlang nach der Ursache suchen.

HEALTH_RESTART_VPN=on ist die Standardeinstellung und sollte aktiviert bleiben. Deaktivieren Sie sie nur, wenn Sie einen bestimmten Fehler untersuchen. Andernfalls bleibt ein ausgefallener Tunnel bei deaktivierter Einstellung ausgefallen.

Reihenfolge: Der Stack darf erst starten, wenn der Tunnel aktiv ist

Das Image enthält einen Docker-Healthcheck:

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

Dieser Befehl startet eine zweite, kurzlebige gluetun-Instanz. Sie fragt den Health-Server der laufenden Instanz unter http://127.0.0.1:9999/ ab. Ein funktionierender Tunnel antwortet mit 200 OK. Ein fehlerhafter Tunnel antwortet mit 500 Internal server error und einer Fehlermeldung. Nach drei aufeinanderfolgenden fehlgeschlagenen Prüfungen markiert Docker den Container als fehlerhaft.

condition: service_healthy wartet genau darauf. Das einfache depends_on: [gluetun] wartet nur, bis der Container gestartet ist. Das geschieht mehrere Sekunden vor dem Abschluss des Handshakes. Die Anwendung startet dann in einem nicht funktionsfähigen Netzwerk und gibt ihren ersten Verbindungsversuch häufig auf. Healthchecks in Docker Compose erläutert die Syntax und die Zeitfelder.

Eine Einschränkung wird häufig übersehen. Compose wertet diese Bedingung beim Start des Stacks aus. Wenn gluetun später fehlerhaft wird, stoppt oder startet Compose die Anwendung nicht automatisch neu. Die interne automatische Wiederherstellung von gluetun deckt diesen Fall ab. Deshalb startet gluetun den VPN-Prozess und nicht den Container neu.

Prüfen Sie auf ein DNS-Leak, bevor Sie der Konfiguration vertrauen

DNS (Domain Name System) ist das Leak, das trotz eines korrekt eingerichteten Tunnels bestehen bleibt. Gluetun führt einen eigenen Resolver innerhalb des Namespace aus und leitet Abfragen standardmäßig über DoT (DNS over TLS) an Cloudflare weiter: DNS_UPSTREAM_RESOLVER_TYPE=dot und DNS_UPSTREAM_RESOLVERS=cloudflare. Lassen Sie beide Einstellungen unverändert. Ihre DNS-Abfragen sind dann verschlüsselt und werden durch den Tunnel übertragen.

Die Einstellung, die dies bei Verwendung eines lokalen Resolvers verhindert, ist DNS_UPSTREAM_PLAIN_ADDRESSES. Sie wird häufig verwendet, wenn ein Name nicht aufgelöst werden kann und stattdessen der Router oder der Resolver des Providers antworten soll. Die Gluetun-Dokumentation warnt, dass Abfragen an einen Resolver im Docker-Bridge-Netzwerk oder im LAN den VPN-Tunnel umgehen. Ein öffentlicher Resolver ohne Verschlüsselung empfängt die Abfragen zwar durch den Tunnel, aber der VPN-Provider kann sie lesen und ändern. Die entsprechende Ursache bei WireGuard wird unter DNS, das über einen WireGuard-Tunnel nicht mehr aufgelöst wird beschrieben.

Setzen Sie zum Testen SHADOWSOCKS=on und SHADOWSOCKS_PASSWORD auf gluetun, veröffentlichen Sie 8388:8388/tcp und 8388:8388/udp, verbinden Sie sich anschließend mit einem Shadowsocks-Client, der UDP-DNS durch den Tunnel überträgt, und öffnen Sie einen DNS-Leak-Test. Im Ergebnis sollten Ihr Provider oder Cloudflare genannt werden, niemals Ihr Heimrouter. Die Gluetun-Dokumentation weist darauf hin, dass einige Leak-Tests ungewöhnliche Ergebnisse melden, weil der Resolver innerhalb des Namespace als lokaler Cache-Vermittler arbeitet und nicht der Server ist, der die Anfrage letztlich beantwortet. Ein falsches Land oder der Resolver Ihres eigenen Internetproviders ist dagegen ein tatsächliches Warnsignal.

Tailscale neben dem VPN-Sidecar hinzufügen und welches gewinnt

Tailscale ist ein auf WireGuard basierendes Overlay-Netzwerk für den Zugriff auf eigene Rechner. Es wird häufig neben einem Provider-VPN betrieben, um einen Administrationszugang zum Stack aufrechtzuerhalten. Das Teilen eines Netzwerk-Namespace bedeutet auch, dass Firewall-Regeln geteilt werden. Deshalb müssen die Firewall- und Routing-Einstellungen beider Komponenten kompatibel sein. Die Tailscale-Dokumentation beschreibt das Standardverhalten: Tailscale fungiert als Overlay-Netzwerk, routet nur Datenverkehr zwischen Geräten, auf denen Tailscale läuft, und greift nicht in den öffentlichen Internetverkehr ein.

Die Antwort hängt daher von einer Einstellung ab.

• Tailscale in einem eigenen Container mit Standardkonfiguration: Der Container sieht den ausgehenden Datenverkehr der Anwendung nie. Gluetun transportiert den gesamten Datenverkehr. Ein Prozess im Tailscale-Container erreicht die Anwendung unter gluetun:8080 über ein gemeinsam genutztes Docker-Netzwerk. Damit Tailnet-Clients diese Verbindung nutzen können, sind Forwarding oder ein Proxy erforderlich.
• Tailscale ist mit network_mode: "service:gluetun" an den Namespace von gluetun angebunden: Im standardmäßigen Userspace-Netzwerkmodus ist TS_USERSPACE aktiviert. Tailscaled erstellt überhaupt kein Interface und arbeitet als SOCKS5- oder HTTP-Proxy. Daher kann es das Routing nicht ändern. Gluetun transportiert den normalen ausgehenden Datenverkehr weiterhin, sofern eine Anwendung diesen Proxy nicht ausdrücklich verwendet.
• Gleiches Szenario mit TS_USERSPACE=false: Tailscale benötigt sein eigenes /dev/net/tun-Gerät und die entsprechenden Capabilities, weil diese nicht mit dem Namespace bereitgestellt werden. Tailscaled erstellt ein Tunnelgerät und installiert unter Linux normalerweise einzelne IPv4-Peer-Routen mit Präfix /32 statt einer einzelnen Route für 100.64.0.0/10. Das alleinige Setzen von TS_USERSPACE=false aktiviert die zusammengefasste Route nicht. Routen zu den Subnetzen anderer Knoten werden nur installiert, wenn Sie --accept-routes über TS_EXTRA_ARGS übergeben. TS_ROUTES funktioniert in die andere Richtung: Es kündigt Subnetze, die dieser Container erreichen kann, an den Rest Ihres Tailnets an. Das entspricht tailscale set --advertise-routes= und fügt hier keine Routen hinzu. Der öffentliche Datenverkehr verlässt das System weiterhin über gluetun.
• Kernel-Netzwerkbetrieb im Namespace von gluetun mit ausgewähltem Exit Node, sudo tailscale set --exit-node=<exit-node-ip>: Tailscale installiert in diesem Namespace Standardrouten. Die Firewall von Gluetun kann diesen Pfad jedoch blockieren. Die Auswahl eines Exit Nodes in einem separaten Container ändert die Routen der Anwendung nicht. Der Userspace-Modus transportiert nur Datenverkehr, der ausdrücklich über seinen Proxy gesendet wird. Kombinieren Sie im Namespace von gluetun keine konkurrierenden Standardrouten. Eine Standardroute, ein Besitzer.

Wenn diese angekündigten Routen der eigentliche Zweck sind und das gesamte private Netzwerk hinter dem Rechner statt nur der Rechner selbst erreichbar sein soll, beschreibt einen Tailscale-Subnet-Router auf einem VPS betreiben die Routenfreigabe, die IP-Weiterleitung und das clientseitige Flag, dessen Aktivierung TS_ROUTES allein nicht erledigt.

Wenn Tailscale einen Administrations-URL bereitstellen soll und nicht als Route benötigt wird, setzen tailscale serve und tailscale funnel HTTPS vor einen lokalen HTTP-Dienst. Nur funnel öffnet diesen Dienst für das öffentliche Internet. In Tailscale v1.104.5 akzeptieren die HTTP-Reverse-Proxys http://gluetun:8080 direkt, wenn der Tailscale-Container über ein gemeinsam genutztes Docker-Netzwerk darauf zugreifen kann. Für ein Ziel, das nicht auf localhost liegt, müssen Sie das Schema http:// angeben. Das Teilen des Netzwerk-Namespace von gluetun und das Ziel http://127.0.0.1:8080 funktionieren ebenfalls.

Ein Nebeneffekt wird sichtbar, wenn Tailscale innerhalb des Tunnels läuft. Seine Peers sehen die Adresse des VPN-Providers. Rechnen Sie daher damit, dass Tailscale häufiger auf Relays zurückfällt. tailscale status zeigt neben einem Peer relay "..." statt direct an, wenn dies geschehen ist. Die Verbindung funktioniert, ist aber langsamer. Wenn Sie tatsächlich nur das Overlay benötigen, ist der Unterschied zwischen einfachem WireGuard und Tailscale der bessere Ausgangspunkt.

Was fehlschlägt und welche Meldung Sie sehen

Docker verweigert das Erstellen des App-Containers. Error response from daemon: conflicting options: port publishing and the container type network mode bedeutet, dass noch ein ports:-Block am angebundenen Dienst hängt. Verschieben Sie ihn zu gluetun.

Compose verweigert die gesamte Datei. Ein Dienst kann nicht gleichzeitig network_mode und networks setzen. Legen Sie die Netzwerke auf gluetun.

Ein anderer Container kann die App nicht auflösen. curl: (6) Could not resolve host: qbittorrent ist das erwartete Verhalten, weil der angebundene Container keinem Netzwerk beigetreten ist und keinen Namen registriert hat. Verwenden Sie gluetun und den Port.

Der zweite angebundene Container startet nicht. Zwei Prozesse in einem Namespace können nicht denselben Port binden. Der unterlegene Prozess meldet, dass die Adresse bereits verwendet wird. Ändern Sie den internen Port der App oder starten Sie ein zweites gluetun.

Die App hat kein Netzwerk mehr, nachdem Sie gluetun geändert haben. Beim Neustart oder Neuerstellen von gluetun wird die Netzwerkverbindung für alle daran angebundenen Container unterbrochen. Starten Sie diese Container neu.

Kleine Seiten werden geladen, große Seiten hängen. Das ist ein MTU-Problem (Maximum Transmission Unit). Der Tunnel fügt zusätzlichen Overhead hinzu. Dadurch werden übergroße Pakete möglicherweise unterwegs verworfen, ohne dass ein Fehler zurückgemeldet wird. Prüfen Sie WIREGUARD_MTU. Der Standardwert in v3.41.3 ist 1320. Verringern Sie den Wert, wenn der Übertragungsweg kleinere Pakete erfordert. Das Entwicklungsimage verwendet die Path-MTU-Erkennung, wenn diese Einstellung nicht gesetzt ist.

Gluetun wird nie als funktionsfähig erkannt. Die Startprüfung nennt die ersten möglichen Ursachen: WARN [vpn] restarting VPN because it failed to pass the healthcheck: startup check: dialing: dial tcp4: lookup cloudflare.com: i/o timeout. Prüfen Sie, ob der Schlüssel abgelaufen ist. Prüfen Sie anschließend, ob die Serverliste veraltet ist. Prüfen Sie danach, ob die Firewall Ihres Hosts ausgehenden UDP-Verkehr blockiert.

FAQ

Warum funktionieren die veröffentlichten Ports meines Containers hinter Gluetun nicht mehr?

Weil network_mode: "service:gluetun" den Container in den Netzwerk-Namespace von gluetun legt. Ein Namespace hat eine IP-Adresse und einen Satz lauschender Ports. Die Anwendung lauscht weiterhin, aber die Portfreigabe muss auf dem Container definiert sein, dem der Namespace gehört. Verschieben Sie die Liste ports: zum gluetun-Service. Wenn sie beim verbundenen Service verblieben ist, erstellt Docker sie nicht einmal: Error response from daemon: conflicting options: port publishing and the container type network mode.

Wie erreiche ich einen Container innerhalb des VPN-Tunnels von einem Container außerhalb des Tunnels?

Verwenden Sie den Servicenamen von gluetun und den Port, auf dem die Anwendung lauscht, zum Beispiel gluetun:8080. Der verbundene Container ist keinem eigenen Docker-Netzwerk zugeordnet. Daher wird sein eigener Name niemals aufgelöst. Für Datenverkehr zwischen Containern müssen keine Ports veröffentlicht werden. In die andere Richtung erreicht ein Container innerhalb des Namespace einen Container außerhalb über dessen Servicenamen, zum Beispiel postgres:5432, unter Gluetun v3.41 und neuer. Ein Client in einem anderen Subnetz, beispielsweise ein Laptop in Ihrem LAN, benötigt einen von gluetuns Firewall und Routing zugelassenen Rückweg. Fügen Sie dieses Subnetz zu FIREWALL_OUTBOUND_SUBNETS hinzu.

Funktioniert Gluetun bei einem VPN-Abbruch als Kill Switch?

Ja, wenn die Firewall aktiviert ist. Der verbundene Container verwendet dieselben Schnittstellen und Routen wie Gluetun. Die Firewall blockiert normalen Internetverkehr außerhalb des Tunnels und lässt gleichzeitig den Endpunkt des VPN-Servers, lokalen Docker-Verkehr und konfigurierte Ausnahmen zu. Gluetun startet das VPN dann intern neu und protokolliert WARN [vpn] restarting VPN because it failed to pass the healthcheck, statt sich zu beenden. Andernfalls würden alle verbundenen Container ihr Netzwerk verlieren, wenn gluetun selbst neu startet.

Tailscale und Gluetun im selben Stack: Welcher Dienst übernimmt den ausgehenden Datenverkehr?

Gluetun übernimmt den normalen ausgehenden Datenverkehr, sofern Sie ihn nicht ausdrücklich über Tailscale senden. Tailscale routet standardmäßig nur Datenverkehr zwischen Geräten in Ihrem Tailnet und lässt öffentlichen Datenverkehr unverändert. Im standardmäßigen Userspace-Modus des Container-Images erstellt Tailscale überhaupt keine Schnittstelle und kann daher das Routing nicht beeinflussen. Mit TS_USERSPACE=false erhält Linux normalerweise einzelne IPv4-Peer-Routen mit /32 statt einer zusammengefassten 100.64.0.0/10-Route. Zusätzlich werden Subnetz-Routen anderer Knoten nur eingerichtet, wenn Sie --accept-routes über TS_EXTRA_ARGS hinzufügen. TS_ROUTES kündigt die Subnetze dieses Containers in Ihrem Tailnet an und fügt keine lokalen Routen hinzu. Wenn Sie mit sudo tailscale set --exit-node=<exit-node-ip> einen Exit-Node auswählen, werden Standardrouten nur in dem Namespace eingerichtet, der Tailscales Kernel-Netzwerk verwendet. Ein separater Container ändert die Routen der Anwendung nicht. Im Userspace-Modus wird nur Datenverkehr über den Proxy weitergeleitet. Legen Sie fest, welches Produkt die Standardroute übernimmt, statt beide zu kombinieren.