Docker Container aus dem Internet erreichbar machen

Was ports: tatsächlich bewirkt

Wenn Sie ports: "8080:80" schreiben, weist Docker den Kernel des Hosts an, Datenverkehr auf Host-Port 8080 an Port 80 im Container weiterzuleiten. Der Service ist dann unter der Adresse des Hosts erreichbar: localhost:8080 auf dem Rechner selbst und etwa 192.168.1.50:8080 von einem Laptop im selben Netz.

Mehr passiert nicht. Ein veröffentlichter Port erreicht den Host und über den Host Ihr lokales Netz. Über Ihren Router hinaus reicht er nicht, und daran ändert keine Compose-Einstellung etwas, weil das Hindernis nicht in Docker liegt.

Private Adressen und die Übersetzung, die sie verbirgt

Sehen Sie sich die Adresse an, die Ihr Rechner in Ihrem Netz hat. Beginnt sie mit 192.168., 10. oder liegt sie zwischen 172.16. und 172.31., ist es eine private Adresse: ein Bereich für die interne Nutzung, den kein Router im öffentlichen Internet weiterleitet. Jedes Gerät in Ihrem Netz hat eine solche Adresse, und jeder Container ebenso.

Ihr Router hält die eine öffentliche IP-Adresse, die Ihnen Ihr Anbieter zugeteilt hat, und leiht sie allen Geräten dahinter, per Network Address Translation, kurz NAT. Baut Ihr Laptop eine Verbindung nach außen auf, ersetzt der Router die Absenderadresse des Pakets durch seine eigene, merkt sich das und schreibt die Antworten so um, dass sie beim anfragenden Gerät ankommen.

Das funktioniert nur in eine Richtung. Eine ausgehende Verbindung legt beim Verlassen ihren eigenen Eintrag in der Tabelle des Routers an. Eine eingehende Verbindung von einem Fremden findet keinen passenden Eintrag und kein Ziel, also wird sie verworfen. Mit einer Portfreigabe legen Sie einen solchen Eintrag von Hand und im Voraus an.

Wenn Sie nicht sicher sind, was Ihr Anschluss Ihnen bietet: Im Leitfaden So bekommen Sie eine öffentliche IP-Adresse steht, wie Sie das prüfen.

CGNAT: Wo eine Portfreigabe keine Option mehr ist

Hinter der ersten Mauer steht eine zweite, und immer mehr Menschen sitzen dahinter.

Vielen Internetanbietern sind die IPv4-Adressen ausgegangen, deshalb führen sie dieselbe Übersetzung eine Ebene höher ein zweites Mal durch. Dann ist auch die WAN-Adresse Ihres Routers privat, meist im Bereich 100.64.0.0/10, und die echte öffentliche Adresse teilen Sie sich mit vielen anderen Kunden. Das ist Carrier-Grade NAT, kurz CGNAT.

Eine Freigaberegel an Ihrem eigenen Router wartet nun auf Datenverkehr, der nie ankommt, denn wohin eine eingehende Verbindung geht, entscheidet sich vorher, auf Geräten, auf die Sie keinen Zugriff haben. Wie Sie feststellen, welche Situation bei Ihnen vorliegt, und welche Anbieter so arbeiten, erklärt der Leitfaden zum Selbst-Hosten hinter Carrier-Grade NAT.

Für einen Compose-Stack kommen vier Ansätze in Frage, und alles, was CGNAT übersteht, tut das aus einem Grund: Es beruht auf einer Verbindung, die Ihr Rechner nach außen aufbaut.

Die vier Wege im Vergleich

Die ersten beiden Spalten entscheiden die meisten Fälle. Mit einer echten öffentlichen IP-Adresse und einem nicht gesperrten Port ist die Portfreigabe kostenlos und kaum zu schlagen. Spricht alles, was Sie betreiben, HTTP, ist Cloudflares Tunnel kostenlos und für diesen Zweck sehr gut. Ausführlicher geht es im Vergleich GetPublicIP vs. Cloudflare Tunnel vs. Tailscale um die Unterschiede.

Die vier Wege im Detail

Welcher Weg zu dem passt, was Sie betreiben

Eine Webanwendung und sonst nichts. Cloudflare Tunnel, es sei denn, Sie legen Wert auf Privatsphäre und echte Ende-zu-Ende-Verschlüsselung.

Nur Ihre eigenen Geräte brauchen Zugriff. Tailscale. Öffentlich muss dann überhaupt nichts erreichbar sein.

Alles, was nicht HTTP ist, oder CGNAT plus mehr als Webverkehr. Eine Portfreigabe, wenn Ihr Anschluss es zulässt, sonst eine eigene öffentliche IP-Adresse.

Läuft Ihr Stack nicht in Docker, gelten dieselben vier Wege. Sie sind im Leitfaden Heimserver aus dem Internet erreichbar machen beschrieben.

So sieht das in einer Compose-Datei aus

Kopierenservices:
  web:
    image: nginx:alpine
    restart: unless-stopped

  getpublicip:
    image: ghcr.io/getpublicip/getpublicip:latest
    restart: unless-stopped
    environment:
      GETPUBLICIP_API_KEY: "${GETPUBLICIP_API_KEY}"
      GETPUBLICIP_MAPPINGS: "80/tcp->web:80; 443/tcp->web:443"
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun
    sysctls:
      net.ipv4.ip_forward: 1
      net.ipv4.conf.all.src_valid_mark: 1
      net.ipv6.conf.all.forwarding: 1

Warum es keine ports:-Einträge gibt

Sehen Sie sich web in dieser Datei noch einmal an. Der Service veröffentlicht nichts. In einem Leitfaden darüber, wie man Container erreichbar macht, lohnt es sich, hier kurz innezuhalten.

Datenverkehr für Ihre öffentliche Adresse kommt im Agent-Container an, auf der Tunnel-Schnittstelle. Der Agent wendet dann eine Destination-NAT-Regel an: dieselbe Art von Regel, die Ihr Router bei einer Portfreigabe anwendet, nur dass sie im Container läuft statt am Rand Ihres Netzes. Sie ersetzt die Zieladresse des Pakets, also die öffentliche Adresse, durch die Adresse des Containers im Compose-Netz und reicht das Paket weiter.

Auf diesem Weg ist kein veröffentlichter Host-Port beteiligt. Der Port ist auf Ihrer öffentlichen IPv4-Adresse offen, nicht auf Ihrem Host und nicht an Ihrem Router. Ein Portscan Ihres Anschlusses zu Hause findet also nichts Neues, das lauscht. Ein ports:-Eintrag bei web würde den Service nur zusätzlich in Ihrem lokalen Netz veröffentlichen, meist das Gegenteil dessen, was Sie wollten.

Ziele werden als Servicenamen statt als Adressen angegeben, weil Compose die Container-Adressen nach eigenem Ermessen vergibt. Der Agent prüft diese Namen standardmäßig alle 30 Sekunden erneut, sodass ein Container, der nach einem Neustart eine andere Adresse hat, weiter erreichbar bleibt.

Was der Container braucht und was nicht

Drei Dinge, alle oben zu sehen: die Capability NET_ADMIN, damit er die Tunnel-Schnittstelle und die Weiterleitungsregeln konfigurieren kann; das Gerät /dev/net/tun, das ist der Tunnel selbst; und die sysctls für die Weiterleitung, damit Datenverkehr, der auf dem Tunnel ankommt, an einen anderen Container weitergegeben werden kann.

privileged: true braucht er nicht. Wenn ein Setup das verlangt, wird etwas umgangen statt konfiguriert. Ein WireGuard-Kernelmodul braucht er ebenfalls nicht: Das Image nutzt es, wenn der Kernel es anbietet, und weicht sonst auf das mitgelieferte Userspace-wireguard-go aus.

Was Sie bekommen, das die Tunnel-Dienste nicht bieten

Jedes Protokoll, nicht nur HTTP. Die Weiterleitung geschieht auf Paketebene, was darüber läuft, ist also Ihre Sache. Ein Minecraft-Server über UDP, ein Mailserver auf 25 und 587, SSH: Jedes davon ist dieselbe Art Mapping wie ein Webserver.

Eine Adresse, die Ihnen gehört. Kein Hostname auf geteilter Infrastruktur. Sie bleibt Ihre, wenn Sie den Stack auf einen anderen Rechner, zu einem anderen Anbieter oder in ein anderes Land umziehen, und DNS-Einträge, die darauf zeigen, überstehen den Umzug.

Reverse DNS. Weil die Adresse Ihnen zugeteilt ist, kann ein PTR-Eintrag für sie gesetzt werden. Die Zustellbarkeit von E-Mails hängt unbedingt davon ab, und deshalb sind Mailserver mit den anderen Ansätzen nicht machbar.

Ihr TLS bleibt Ihres. GetPublicIP leitet Pakete weiter und terminiert nie TLS, auf unserer Seite liegen also keine Zertifikate oder Schlüssel. Die Sitzung wird zwischen Ihrem Besucher und dem Container ausgehandelt, der sie bei Ihnen terminiert, und erst dort zum ersten Mal entschlüsselt. Dieser Service braucht ein eigenes gültiges Zertifikat, wie auf jedem öffentlichen Host.

Typische Stolperfallen

Häufig gestellte Fragen

Wie es weitergeht

Wenn eine eigene öffentliche IP-Adresse zu dem passt, was Sie betreiben, finden Sie in der Docker-Dokumentation die vollständige Referenz: die gesamte Mapping-Syntax, ein funktionierendes Beispiel, IPv6, die Weiterleitung an einen Service auf dem Docker-Host und die Hinweise für die einzelnen Plattformen.