Gluetun Container Zugriff auf Host und Netzwerk

Was passiert, wenn ein Container dem Netzwerk von gluetun beitritt

Ein Container, der network_mode: service:gluetun setzt, hat keine eigenen Netzwerkschnittstellen. Er tritt dem Netzwerk-Namespace von gluetun bei. Dadurch sind Port-Freigaben und Firewall-Regeln keine Eigenschaften dieses Containers mehr, sondern des gluetun-Dienstes. Alle folgenden Antworten ergeben sich aus dieser einen Tatsache.

Ein Netzwerk-Namespace ist eine private Kopie des Netzwerk-Stacks im Kernel. Er verfügt über eigene Schnittstellen, eine eigene Routing-Tabelle, eigene Firewall-Regeln und eigene Listening-Sockets. Docker erstellt standardmäßig für jeden Container einen solchen Namespace. Wenn Sie network_mode: service:gluetun angeben, überspringt Docker diesen Schritt und fügt den neuen Container in den Namespace ein, den gluetun bereits verwendet. Der Container behält sein eigenes Dateisystem, aber nicht seine eigenen /etc/hosts oder /etc/resolv.conf. Docker stellt ihm dieselben Dateien bereit, die gluetun verwendet. Das ist später wichtig.

Sie können dies direkt prüfen.

docker inspect -f '{{.HostConfig.NetworkMode}}' qbittorrent

Die Ausgabe enthält container:, gefolgt von der Container-ID von gluetun. Bei einem normalen Container würde dort bridge ausgegeben. Dieser Leitfaden setzt an der Stelle fort, an der Docker-Verkehr über ein VPN mit gluetun routen endet: Der Tunnel funktioniert, und jetzt kann niemand mehr mit dem Container kommunizieren.

Port auf gluetun veröffentlichen, nicht auf der Anwendung

Lassen Sie auf dem Dienst, der network_mode setzt, keinen ports:-Block stehen. Docker verweigert sonst die Erstellung des Containers:

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

Der Grund ist direkt. Das Veröffentlichen eines Ports fügt eine NAT-Regel (Network Address Translation) hinzu, die einen Host-Port in den eigenen Netzwerk-Namespace eines Containers weiterleitet. Dieser Container hat jedoch keinen eigenen Netzwerk-Namespace. Verschieben Sie das Mapping auf den gluetun-Dienst. Die Portnummer ändert sich nicht, weil die Anwendung weiterhin auf diesem Port innerhalb des gemeinsam genutzten Namespace lauscht.

services:
  gluetun:
    ports:
      - "8080:8080/tcp"   # qBittorrent web UI

  qbittorrent:
    network_mode: "service:gluetun"
    # no ports: block here

Ein expose:-Block auf dem abhängigen Dienst schlägt aus demselben Grund mit conflicting options: port exposing and the container type network mode fehl. Auch ein networks:-Block führt dort zum Abbruch: Compose meldet, dass der Dienst sich gegenseitig ausschließende network_mode und networks deklariert, und verweigert das Laden der Datei vollständig.

Eine Folge davon zeigt sich später. Alle Container in diesem Namespace teilen sich einen einzigen Portbereich. Zwei Anwendungen, die beide standardmäßig Port 8080 verwenden, kollidieren daher. Die Anwendung, die als zweite startet, schlägt mit einem Fehler wegen einer bereits verwendeten Adresse fehl. Ändern Sie den Port einer der Anwendungen in ihrer eigenen Konfiguration, beispielsweise die Variable WEBUI_PORT im LinuxServer-qBittorrent-Image. Veröffentlichen Sie anschließend die neue Nummer auf gluetun.

Wie erreichen sich Container hinter gluetun?

Innerhalb des Namespace teilen sie bereits eine Loopback-Schnittstelle. Ein Container hinter gluetun erreicht seinen benachbarten Container unter 127.0.0.1:<port>, ohne dass ein Docker-Netzwerk beteiligt ist.

Außerhalb des Namespace hat der Container keinen Namen. Der integrierte DNS-Server von Docker löst einen Servicenamen in die Adresse dieses Dienstes in einem benutzerdefinierten Netzwerk auf. Dieser Container hat jedoch keine Adresse in einem Netzwerk. Ein normaler Container wie Sonarr erreicht den Torrent-Client daher nicht unter http://qbittorrent:8080. Er erreicht ihn unter http://gluetun:8080, weil der Socket im Namespace von gluetun auf der Adresse von gluetun lauscht. Das überrascht Nutzer, die wissen, wie Docker-Compose-Netzwerke und Servicenamen funktionieren, und erwarten, dass die übliche Namensauflösung gilt. Es funktioniert auch ohne Veröffentlichung eines Ports auf dem Host, da sich beide Container im selben Compose-Netzwerk befinden.

Prüfen Sie DNS, bevor Sie etwas anderes untersuchen. Gluetun betreibt seinen eigenen DNS-Server innerhalb des Namespace. Docker gibt jedem Container hinter gluetun dieselbe /etc/resolv.conf-Datei wie gluetun. Dadurch laufen die Namensauflösungen Ihrer Anwendung über den Resolver von gluetun und nicht über den Resolver des Hosts. Standardmäßig verweigert dieser Resolver außerdem Antworten, die auf private Adressen verweisen. Deshalb kann ein Name, der auf dem Host aufgelöst wird, innerhalb des Containers fehlschlagen. Die gluetun-Dokumentation weist darauf hin, dass solche Hostnamen in DNS_REBINDING_PROTECTION_EXEMPT_HOSTNAMES eingetragen werden müssen.

docker exec qbittorrent cat /etc/resolv.conf

Wie erreiche ich einen Dienst, der auf dem Docker-Host läuft?

Verwenden Sie host.docker.internal. Dafür sind zwei Einstellungen erforderlich, beide am gluetun-Dienst, weil zwei unterschiedliche Dinge nicht funktionieren.

Zuerst kommt der Name. Ein Container hinter gluetun liest gluetuns /etc/hosts, und Docker lehnt einen extra_hosts-Eintrag bei einem Dienst ab, der network_mode mit conflicting options: custom host-to-IP mapping and the network mode setzt. Der Eintrag gehört daher zu gluetun, und jeder Container im Namespace sieht ihn.

  gluetun:
    extra_hosts:
      - "host.docker.internal:host-gateway"

host-gateway ist ein spezieller Wert, den Docker durch eine interne Adresse des Hosts selbst ersetzt. Bei einer normalen Linux-Docker-Installation ist das die Adresse der docker0-Bridge, häufig 172.17.0.1. Prüfen Sie Ihre Adresse mit ip -4 addr show docker0 auf dem VPS. Docker Desktop löst diesen Namen selbst auf. Deshalb lassen Anleitungen für einen Laptop die Zeile extra_hosts aus, während dieselbe Datei auf einem Server fehlschlägt.

Danach kommt die Route. Der Name teilt dem Container nur mit, welche Adresse er verwenden soll. Das Paket verlässt den Container weiterhin über gluetuns Standardroute. Diese führt durch den Tunnel, und gluetuns Firewall verwirft das Paket. Das Symptom ist eine Verbindung, die hängen bleibt und schließlich in einem Timeout endet, nicht eine Verbindung, die abgelehnt wird. Bei einer Ablehnung ist das Paket angekommen und ein Dienst hat mit Nein geantwortet. Bei einem Timeout ist es nicht angekommen.

  gluetun:
    environment:
      - FIREWALL_OUTBOUND_SUBNETS=172.17.0.1/32

Prüfen Sie anschließend, ob der Dienst auf dem Host tatsächlich an dieser Adresse lauscht. Ein PostgreSQL-Server, der nur an 127.0.0.1 gebunden ist, ist aus keinem Container mit eigenem Netzwerknamespace erreichbar. Das gilt für jeden Container hinter gluetun, unabhängig davon, ob ein Tunnel verwendet wird. Der Grund ist, dass 127.0.0.1 innerhalb des Namespace auf die Loopback-Schnittstelle dieses Namespace verweist. Nur ein Container mit Host-Netzwerk verwendet die Loopback-Schnittstelle des Hosts gemeinsam mit dem Host. Ein Container hinter gluetun hat sein network_mode jedoch bereits für gluetun verwendet. Binden Sie PostgreSQL stattdessen an 172.17.0.1. Dann akzeptiert PostgreSQL Verbindungen aus Containern, bleibt aber von der öffentlichen Schnittstelle getrennt. Prüfen Sie dies auf dem Host mit ss -lntp | grep 5432.

Was FIREWALL_OUTBOUND_SUBNETS tatsächlich ändert

Die Gluetun-Dokumentation beschreibt die Variable als kommagetrennte Subnetze, auf die Gluetun und die Container mit gemeinsamem Netzwerk-Stack zugreifen dürfen. Außerdem weist sie darauf hin, dass dafür Änderungen an Firewall und Routing erforderlich sind. Beide Aspekte sind relevant. Gluetun fügt für jedes aufgeführte Subnetz eine Route über das Docker-Bridge-Gateway hinzu. Pakete für diese Adressen verlassen das System daher über eth0 statt über den Tunnel. Zusätzlich öffnet Gluetun die Firewall für diese Subnetze. Andernfalls verwirft Gluetun ausgehenden Datenverkehr, der nicht für den VPN-Server bestimmt ist.

Geben Sie den Wert ohne Leerzeichen nach den Kommas an.

      - FIREWALL_OUTBOUND_SUBNETS=172.17.0.1/32,192.168.1.0/24,100.64.7.9/32

Zwei Eigenschaften werden leicht übersehen. Die Einstellung gilt auf Namespace-Ebene. Sie betrifft daher jeden Container hinter Gluetun und nicht nur den vorgesehenen Container. Außerdem gilt sie nur für ausgehenden Datenverkehr. Sie steuert Verbindungen, die ein Container selbst startet. Verbindungen, die an einem veröffentlichten Port eingehen, nehmen einen anderen Pfad und benötigen hier keinen Eintrag.

Zugriff auf die Weboberfläche von einem Tailscale-Peer

Tailscale weist jedem Rechner eine Adresse aus 100.64.0.0/10 zu. Dieser Bereich ist für Carrier-Grade-NAT reserviert. In einem persönlichen Tailnet entstehen dafür keine Kosten. Allerdings entscheidet die Begrenzung des kostenlosen Tarifs auf sechs Benutzer, ob das so bleibt, sobald weitere Personen auf dieselben Oberflächen zugreifen müssen. Benutzergeräte sind in jedem Tarif unbegrenzt. Server und andere getaggte Geräte werden separat gezählt. Auf der Tailscale-Preisseite sind 50 getaggte Ressourcen enthalten. Jede weitere Ressource kostet 1 $ pro Monat. Da für die Abrechnung ansonsten Benutzer und nicht Rechner gezählt werden, hängt der tatsächliche Preis eines kostenpflichtigen Tailnets hauptsächlich davon ab, wie viele Personen Sie einladen, und nicht davon, wie viele Container Sie für sie freigeben. Die beiden Richtungen erfordern unterschiedliche Maßnahmen.

Eingehende Verbindungen sind der einfache Fall. Wenn Sie 8080:8080 auf gluetun veröffentlichen, wird dieser Port an allen Adressen des Hosts gebunden. Die tailscale0-Schnittstelle des Hosts gehört dazu. Ein Peer öffnet daher http://<machine-name>:8080 und erreicht den Container. Gluetun ist an diesem Pfad nicht beteiligt, weil die NAT-Regel von Docker auf dem Host außerhalb des Namespace liegt.

Damit die Weboberfläche nur über das Tailnet erreichbar ist, binden Sie den veröffentlichten Port an die Tailscale-Adresse des Hosts und nicht an alle Adressen.

    ports:
      - "100.101.102.103:8080:8080/tcp"

Ermitteln Sie diese Adresse auf dem Host mit tailscale ip -4. Das Binden ist hier eine wirksamere Kontrolle als eine Firewall-Regel, weil der Port an der öffentlichen Schnittstelle überhaupt nicht geöffnet wird. Wenn Sie die Weboberfläche lieber über einen HTTPS-Namen statt über Host und Port aufrufen möchten, kann tailscale serve den veröffentlichten Port davor schalten. Allerdings unterscheiden sich serve und funnel darin, wer letztlich darauf zugreifen kann, und nur eine der beiden Varianten hält die Weboberfläche im Tailnet. Dadurch wird außerdem das Problem umgangen, dass Docker veröffentlichte Ports direkt an ufw vorbei weiterleitet. Das Tailscale-Sidecar-Muster für Compose geht noch weiter und entfernt den Host-Port vollständig. Es funktioniert jedoch, indem die Anwendung in den Netzwerk-Namespace des Sidecars verschoben wird. Ein Container hinter gluetun hat sein einziges network_mode bereits für gluetun verwendet.

Bei ausgehenden Verbindungen tritt FIREWALL_OUTBOUND_SUBNETS wieder auf. Wenn ein Container einen Peer aufrufen muss, fügen Sie die Adresse dieses Peers hinzu. Bevorzugen Sie pro Peer ein /32 statt des gesamten /10. Wenn sich das Zielsystem in einem privaten Netzwerk befindet, das über einen VPS erreichbar ist, der dieses Subnetz in Ihrem Tailnet bekannt gibt, tragen Sie den bekannt gegebenen Bereich statt der eigenen 100.x-Adresse des Routers ein. Prüfen Sie außerdem, ob der Host selbst diese Routen akzeptiert hat. MagicDNS-Namen werden im Container standardmäßig nicht aufgelöst, weil der Container den DNS-Server von gluetun statt des Resolvers des Hosts verwendet. Verwenden Sie daher die numerische 100.x-Adresse oder hinterlegen Sie den Namen mit einer extra_hosts-Zeile im gluetun-Dienst. Die DNS_UPSTREAM_PLAIN_ADDRESSES-Option von gluetun kann Abfragen stattdessen an einen anderen Resolver weiterleiten. Dabei werden jedoch alle Abfragen unverschlüsselt übertragen. Die gluetun-Dokumentation rät davon ab, weil Abfragen an eine private Adresse aus dem VPN-Tunnel heraus gelangen. Dasselbe gilt, wenn Sie Ihren eigenen Tailscale-Control-Server mit Headscale betreiben.

Eine vollständige Compose-Datei für das übliche Muster

Ein Download-Client hinter dem VPN, zwei Web-UIs, die nur im Tailnet erreichbar sind, und ein Container, der eine auf dem Host laufende PostgreSQL-Datenbank liest.

services:
  gluetun:
    image: qmcgaw/gluetun:latest
    container_name: gluetun
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun
    ports:
      - "127.0.0.1:8000:8000/tcp"        # gluetun control server, host only
      - "100.101.102.103:8080:8080/tcp"  # qBittorrent UI, tailnet only
      - "100.101.102.103:9696:9696/tcp"  # Prowlarr UI, tailnet only
    extra_hosts:
      - "host.docker.internal:host-gateway"
    volumes:
      - ./gluetun:/gluetun
    environment:
      - VPN_SERVICE_PROVIDER=mullvad
      - VPN_TYPE=wireguard
      - WIREGUARD_PRIVATE_KEY=${WIREGUARD_PRIVATE_KEY}
      - WIREGUARD_ADDRESSES=${WIREGUARD_ADDRESSES}
      - SERVER_CITIES=Amsterdam
      - FIREWALL_OUTBOUND_SUBNETS=172.17.0.1/32,100.64.7.9/32
      - TZ=Europe/Amsterdam
    restart: unless-stopped

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

  prowlarr:
    image: lscr.io/linuxserver/prowlarr:latest
    network_mode: "service:gluetun"
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Amsterdam
      - PROWLARR__POSTGRES__HOST=host.docker.internal
      - PROWLARR__POSTGRES__PORT=5432
      - PROWLARR__POSTGRES__USER=prowlarr
      - PROWLARR__POSTGRES__PASSWORD=${PROWLARR_DB_PASSWORD}
      - PROWLARR__POSTGRES__MAINDB=prowlarr-main
      - PROWLARR__POSTGRES__LOGDB=prowlarr-log
    volumes:
      - ./prowlarr:/config
    depends_on:
      gluetun:
        condition: service_healthy
    restart: unless-stopped

Lesen Sie die Datei wegen des Musters und nicht wegen der Produktnamen. Beide UIs werden auf gluetun veröffentlicht und an die Tailnet-Adresse des Hosts gebunden. Sie sind daher über Tailscale und sonst nirgendwo erreichbar. Die Zeile extra_hosts befindet sich ebenfalls auf gluetun, weil Prowlarr beim Auflösen von host.docker.internal gluetuns /etc/hosts liest und Docker die Zeile auf Prowlarr selbst ablehnen würde. FIREWALL_OUTBOUND_SUBNETS nennt zwei einzelne Adressen: die Docker-Bridge-Adresse des Hosts, damit Prowlarr eine Datenbankverbindung öffnen kann, und einen Tailnet-Peer.

Der PostgreSQL-Server fehlt absichtlich in der Datei. Er läuft auf dem VPS als gewöhnlicher Systemdienst und lauscht auf 172.17.0.1:5432. Das entspricht derselben Schichtung wie ein arr-Stack mit Docker Compose, wobei die Datenbank außerhalb von Docker läuft.

Halten Sie den privaten WireGuard-Schlüssel aus der Compose-Datei heraus. ${WIREGUARD_PRIVATE_KEY} liest ihn aus einer .env-Datei daneben. Dieses Muster wird unter Env-Dateien und Secrets für Docker Compose beschrieben. Die condition: service_healthy-Klausel verwendet den Healthcheck, den das gluetun-Image bereits mitliefert. Daher startet nichts, bevor der Tunnel seinen Betriebszustand meldet. Compose-Healthchecks erläutern die allgemeine Form.

    ports:
      - "8080:8080/tcp"

Prüfen, ob der Tunnel weiterhin Datenverkehr überträgt

Führen Sie dieselbe Anfrage zweimal aus: einmal innerhalb des Namespace und einmal auf dem Host. Vergleichen Sie anschließend die Ergebnisse.

docker run --rm --network=container:gluetun curlimages/curl:latest -s https://api.ipify.org
curl -s https://api.ipify.org

Die erste Ausgabe sollte die Exit-Adresse Ihres VPN-Anbieters anzeigen. Die zweite sollte die Adresse des VPS anzeigen. Stimmen die Adressen überein, läuft der Datenverkehr des Containers nicht durch den Tunnel. Alle weiteren Schritte in diesem Leitfaden sind dann wirkungslos, bis dieses Problem behoben ist.

Anhand der Routing-Regeln und Routing-Tabellen sehen Sie, welcher Datenverkehr den Tunnel umgeht.

docker run --rm --network=container:gluetun alpine:3.22 sh -c 'ip rule show; ip route show table 51820; ip route show table 199'

Bei der WireGuard-Konfiguration in diesem Leitfaden nennt gluetun die Tunnel-Schnittstelle wg0. Der Name tun0 ist ausschließlich der Standardwert für OpenVPN. Gluetun hält die Default-Route des Tunnels außerdem aus der Haupt-Routing-Tabelle heraus. ip rule show sollte eine Regel enthalten, die sämtlichen Datenverkehr, den WireGuard selbst nicht markiert, an Tabelle 51820 weiterleitet. Diese Tabelle sollte auf wg0 eine Default-Route enthalten. Tabelle 199 enthält für jeden Eintrag in FIREWALL_OUTBOUND_SUBNETS eine Route, die jeweils auf das Docker-Bridge-Gateway unter eth0 zeigt. Die zugehörige Regel wird direkt vor der Tunnel-Regel geprüft. Ein einfaches ip route show führt weiterhin die eigene Default-Route von Docker auf eth0 auf. Das ist erwartungsgemäß und stellt kein Leck dar, weil beide Regeln von gluetun vor der Haupttabelle geprüft werden. Jede Route in Tabelle 199, die Sie nicht angegeben haben, beschreibt Datenverkehr, der das VPN umgeht.

Der Control Server von gluetun kann unter /v1/publicip/ip auf Port 8000 dieselbe öffentliche IP-Adresse melden. Standardmäßig funktioniert dies jedoch erst, nachdem Sie die Authentifizierung eingerichtet haben. Laut der gluetun-Dokumentation sind alle Routen des Control Server inzwischen standardmäßig privat. Eine einfache Anfrage an diesen Pfad schlägt daher fehl. Konfigurieren Sie den Server mit einer Auth-Datei, die unter /gluetun/auth/config.toml eingebunden wird, und verwenden Sie dazu die Methode basic oder apikey. Starten Sie gluetun anschließend neu. Die Compose-Datei weiter oben bindet ./gluetun bereits unter /gluetun ein. Die Datei muss daher auf dem Host unter ./gluetun/auth/config.toml liegen. Die Variable HTTP_CONTROL_SERVER_AUTH_DEFAULT_ROLE ist der schnellere Weg. Wenn Sie sie auf {"auth":"none"} setzen, wird die Authentifizierung vollständig deaktiviert. Laut Dokumentation wird dies ausdrücklich nicht empfohlen. Bei einer Version vor v3.39.1 ist der Server auf diese Weise nicht geschützt. Die Dokumentation warnt deshalb davor, allen erreichbaren Clients zu vertrauen.

Ein falsches Subnetz öffnet eine zu große Lücke

FIREWALL_OUTBOUND_SUBNETS ist eine absichtlich in der Firewall geöffnete Lücke. Die Größe dieser Lücke entspricht daher der Größe des Risikos. Es gibt vier Möglichkeiten, sie zu groß zu machen:

• 0.0.0.0/0 leitet den gesamten Datenverkehr außerhalb des Tunnels weiter. Die beiden IP-Prüfungen weiter oben erkennen das bereits beim ersten Durchlauf, weil sie dieselbe Adresse zurückgeben.
• Ein Bereich, der größer als das Ziel ist. Wenn Sie 10.0.0.0/8 öffnen, um einen einzelnen Rechner unter 10.0.1.7 zu erreichen, öffnen Sie auch jede Adresse, die ein Torrent-Peer in diesem Bereich bekanntgeben könnte. Schreiben Sie 10.0.1.7/32.
• Ein Bereich, der sich mit den eigenen Adressen des Tunnels überschneidet. Die gluetun-Dokumentation warnt davor, dass gluetun dadurch den VPN-Datenverkehr stattdessen über die Bridge sendet. Das verhindert Portweiterleitung. Prüfen Sie den Wert WIREGUARD_ADDRESSES, bevor Sie einen privaten Bereich öffnen.
• 100.64.0.0/10 für Tailscale. Damit werden grob vier Millionen Adressen geöffnet, damit ein Peer erreicht werden kann. Führen Sie die benötigten Peers als /32-Einträge auf.

Beachten Sie, dass diese Einstellung für den gesamten Namespace gilt. Wenn Sie ein Subnetz öffnen, damit ein Indexer einen Hostdienst erreichen kann, wird dasselbe Subnetz auch für den Torrent-Client geöffnet, der diesen Namespace verwendet. Führen Sie die Prüfung der öffentlichen IP-Adresse nach jeder Änderung an dieser Variablen erneut aus. Nur mit dieser Prüfung lässt sich feststellen, ob die Änderung tatsächlich das bewirkt hat, was Sie beabsichtigt haben.

Was beim Neustart von gluetun ausfällt

gluetun besitzt den Namespace. Daher entspricht der Lebenszyklus von gluetun dem Lebenszyklus des Namespace. Wenn Sie einen abhängigen Container starten, während gluetun nicht läuft, schlägt der Start sofort fehl:

Error response from daemon: cannot join network namespace of a non running container: container <id> is exited

Ein Neustart von gluetun an Ort und Stelle führt zu einem weniger offensichtlichen Fehler. Die abhängigen Container laufen weiter, während der Namespace, an den sie angebunden sind, unter ihnen neu erstellt wird. Daher meldet docker ps einen vollständig gesunden Zustand, obwohl keine Antwort eingeht. Nach jeder Änderung am gluetun-Dienst sollten Sie die gesamte Gruppe neu erstellen, statt nur einen Teil davon neu zu starten.

docker compose up -d --force-recreate

Dasselbe gilt für Image-Aktualisierungen. Wenn Sie ein neues gluetun-Image abrufen und nur diesen Dienst neu erstellen, verweisen die übrigen Container weiterhin auf einen Namespace, der nicht mehr existiert.

FAQ

Warum meldet Docker „port publishing and the container type network mode“?

Weil in einem Dienst weiterhin ein ports:-Block vorhanden ist, der gleichzeitig network_mode: service:gluetun setzt. Die Veröffentlichung eines Ports fügt eine NAT-Regel hinzu, die einen Host-Port in den eigenen Netzwerk-Namespace eines Containers weiterleitet. Ein Container in diesem Modus hat jedoch keinen eigenen Netzwerk-Namespace. Löschen Sie den ports:-Block aus diesem Dienst und fügen Sie dasselbe Mapping zum gluetun-Dienst hinzu. Die Portnummer bleibt unverändert, da die Anwendung weiterhin innerhalb des gemeinsam genutzten Namespace auf diesem Port lauscht.

Wie erreichen andere Container einen Dienst hinter gluetun?

Container im selben Namespace erreichen einander unter 127.0.0.1. Container außerhalb dieses Namespace verwenden den Namen des gluetun-Dienstes. Daher funktioniert http://gluetun:8080, während http://qbittorrent:8080 nicht funktioniert. Der Anwendungscontainer besitzt keine Adresse in einem Docker-Netzwerk. Der integrierte DNS-Server kann seinen Namen daher nicht auflösen. Dafür ist keine Portveröffentlichung erforderlich, solange beide Container ein Compose-Netzwerk gemeinsam verwenden.

Was sollte ich in FIREWALL_OUTBOUND_SUBNETS eintragen?

Nur die Adressen, zu denen ein Container hinter gluetun eine Verbindung aufbauen muss. Tragen Sie sie so eng wie möglich ein. Ein einzelner Rechner wird als /32 angegeben. Die beiden häufigsten Einträge sind der Docker-Host unter 172.17.0.1/32 und jeweils ein /32 für jeden Tailscale-Peer, den Sie erreichen. Fügen Sie niemals 0.0.0.0/0 hinzu. Fügen Sie außerdem niemals einen Bereich hinzu, der sich mit den eigenen Tunneladressen Ihres VPN überschneidet. Eingehende Verbindungen zu einem veröffentlichten Port benötigen hier keinen Eintrag.

Warum kann der Container meine Tailscale-MagicDNS-Namen nicht auflösen?

MagicDNS funktioniert, indem der Resolver des Hosts auf den DNS-Server von Tailscale verweist. Der Container verwendet jedoch nicht den Resolver des Hosts. Er verwendet den /etc/resolv.conf, den er mit gluetun gemeinsam nutzt. Dieser verweist auf den DNS-Server von gluetun. Prüfen Sie dies mit docker exec <container> cat /etc/resolv.conf. Verwenden Sie die numerische 100.x-Adresse des Peers oder ordnen Sie den Namen mit einem extra_hosts-Eintrag im gluetun-Dienst fest zu. Gluetun kann Abfragen mit DNS_UPSTREAM_PLAIN_ADDRESSES an einen anderen Resolver weiterleiten. Dabei werden sie jedoch unverschlüsselt übertragen, und die Dokumentation rät davon ab.

Wie bestätige ich, dass der Datenverkehr weiterhin über das VPN läuft?

Führen Sie eine Anfrage innerhalb des Namespace und dieselbe Anfrage auf dem Host aus. Vergleichen Sie anschließend die Antworten. docker run --rm --network=container:gluetun curlimages/curl:latest -s https://api.ipify.org sollte die Exit-Adresse Ihres VPN-Anbieters zurückgeben, während curl -s https://api.ipify.org auf dem VPS die Adresse des VPS zurückgeben sollte. Zwei übereinstimmende Antworten bedeuten, dass der Tunnel den Datenverkehr des Containers nicht überträgt. Wiederholen Sie diese Prüfung nach jeder Änderung an FIREWALL_OUTBOUND_SUBNETS.