Hallo zusammen,
Ich benötige mal Eure Hilfe. Ich scheitere gerade am Grundverständnis, wo mein Problem liegt.
Ich habe einen Raspi 5. Der hängt an einem Telekomrouter und ist über einen DynDNS-Provider (Selfhost.de) ansprechbar.
Auf dem Raspi habe ich Docker drauf installiert. (Ich habe 0 Erfahrung damit und möchte mich damit beschäftigen.) Erstes Spielobjekt ist Nextcloud. (Ist für mich auch neu.) Dazu habe ich mir von "hub.docker.com" "nextcloud/all-in-one" runtergeladen.
Nächster Schritt war die zur Verfügung gestellte Installationsanleitung abzuarbeiten: https://nextcloud.com/blog/how-to-install-the-nextcloud-all-in-one-on-linux/ Die Konfigurationsseite habe ich zuerst von Intern aufgerufen https://127.0.0.1:8080
Beim Punkt 7 der Anleitung - Angabe der Domaine - war die Erfolgsstory auch schon beendet.
Wenn ich im Feld für die Domaine den Namen, über den der Rechner erreichbar ist, nenne wir ihn mal zum Beispiel raspi5.selfhost.eu, eintrage, kommt die Meldung das die Seite nicht erreichbar ist:
The domain is not reachable on Port 443 from within this container. Have you opened port 443/tcp in your router/firewall? If yes is the problem most likely that the router or firewall forbids local access to your domain. You can work around that by setting up a local DNS-server.
Ok! Das hängt mit dem Telekomrouter zusammen, dachte ich mir. Der bekommt es sicherlich nicht hin, Anfragen, die von intern kommen, sauber raus und dann wieder hinein zu routen. In der Datei /etc/hosts habe ich deshalb die interne IP vom Raspi eingetragen: 192.168.2.128 raspi5.selfhost.eu
(Im Telekomrouter gibt es eine Weiterleitung auf den Port 443 und Port 3478, wie in der Anleitung beschrieben)
Das hilft aber nicht. Die Fehlermeldung bleibt.
Ebenso hilft es nicht die IP's der Dockernetzwerke anzugeben (172.18.0.1; 172.17.0.1; 172.18.0.3).
---- Die IP vom Docker ist laut ifconfig ----
br-ae134de8761d: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 172.18.0.1 netmask 255.255.0.0 broadcast 172.18.255.255 inet6 fe80::58a0:89ff:fe51:5669 prefixlen 64 scopeid 0x20<link> ...
docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255 inet6 fe80::6458:deff:feea:4a47 prefixlen 64 scopeid 0x20<link> ...
---- Die Ausgabe zu "iptables-nft -L -n -v" ----
Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 5677 648K DOCKER-USER 0 -- * * 0.0.0.0/0 0.0.0.0/0 5677 648K DOCKER-FORWARD 0 -- * * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination
Chain DOCKER (2 references) pkts bytes target prot opt in out source destination 4 240 ACCEPT 6 -- !br-ae134de8761d br-ae134de8761d 0.0.0.0/0 172.18.0.3 tcp dpt:443 0 0 ACCEPT 6 -- !br-ae134de8761d br-ae134de8761d 0.0.0.0/0 172.18.0.2 tcp dpt:8443 8 424 ACCEPT 6 -- !br-ae134de8761d br-ae134de8761d 0.0.0.0/0 172.18.0.2 tcp dpt:8080 5 252 ACCEPT 6 -- !br-ae134de8761d br-ae134de8761d 0.0.0.0/0 172.18.0.2 tcp dpt:80 0 0 ACCEPT 6 -- !docker0 docker0 0.0.0.0/0 172.17.0.2 tcp dpt:9443 0 0 ACCEPT 6 -- !docker0 docker0 0.0.0.0/0 172.17.0.2 tcp dpt:8000 0 0 DROP 0 -- !docker0 docker0 0.0.0.0/0 0.0.0.0/0 0 0 DROP 0 -- !br-ae134de8761d br-ae134de8761d 0.0.0.0/0 0.0.0.0/0
Chain DOCKER-BRIDGE (1 references) pkts bytes target prot opt in out source destination 0 0 DOCKER 0 -- * docker0 0.0.0.0/0 0.0.0.0/0 605 32556 DOCKER 0 -- * br-ae134de8761d 0.0.0.0/0 0.0.0.0/0
Chain DOCKER-CT (1 references) pkts bytes target prot opt in out source destination 77 26152 ACCEPT 0 -- * docker0 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED 2137 309K ACCEPT 0 -- * br-ae134de8761d 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
Chain DOCKER-FORWARD (1 references) pkts bytes target prot opt in out source destination 5677 648K DOCKER-CT 0 -- * * 0.0.0.0/0 0.0.0.0/0 3463 313K DOCKER-ISOLATION-STAGE-1 0 -- * * 0.0.0.0/0 0.0.0.0/0 3463 313K DOCKER-BRIDGE 0 -- * * 0.0.0.0/0 0.0.0.0/0 83 11761 ACCEPT 0 -- docker0 * 0.0.0.0/0 0.0.0.0/0 2775 269K ACCEPT 0 -- br-ae134de8761d * 0.0.0.0/0 0.0.0.0/0
Chain DOCKER-ISOLATION-STAGE-1 (1 references) pkts bytes target prot opt in out source destination 83 11761 DOCKER-ISOLATION-STAGE-2 0 -- docker0 !docker0 0.0.0.0/0 0.0.0.0/0 2775 269K DOCKER-ISOLATION-STAGE-2 0 -- br-ae134de8761d !br-ae134de8761d 0.0.0.0/0 0.0.0.0/0
Chain DOCKER-ISOLATION-STAGE-2 (2 references) pkts bytes target prot opt in out source destination 0 0 DROP 0 -- * br-ae134de8761d 0.0.0.0/0 0.0.0.0/0 0 0 DROP 0 -- * docker0 0.0.0.0/0 0.0.0.0/0
Chain DOCKER-USER (1 references) pkts bytes target prot opt in out source destination
---- Ende ----
Habt Ihr eine Idee warum der Port 443 aus dem Container heraus als nicht erreichbar gilt?
Hat das manchmal mit dem Zertifikat zu tun? Kann es sein, dass die oben geschriebene Fehlermeldung eigentlich in die Irre führt, der Port offen ist, aber das Zertifikat die Kommunikation verhindert?
Wenn ich von außerhalb auf raspi5.selfhost.eu zugreife, kommt ein ERR_SSL_Protocol_ERR.
Wenn ich von intern auf raspi5.selfhost.eu zugreife kommt SSL_ERROR_RX_RECORD_TOO_LONG
Viele Grüße
Andreas
Hallo Andreas,
ich würde dir sowohl bei der Nextcloud im speziellen, als auch allgemein von Docker abraten. Ich habe grundsätzlich nichts gegen Container, wenn sie vernünftig gebaut sind, aber die Konstellation ist kein guter Start.
Die Nextcloud funktioniert im Container schlechter als standalone. Updates fordern mehr (manuelle) Nacharbeit, als einfach nur den Container zu aktualisieren. Wenn ein Plugin da drin nicht funktioniert ist die Fehlersuche komplizierter. All-in-one hab ich nie richtig zum laufen gebracht.
Docker (der Daemon) ist eine Zumutung, vollkommem irrationales Verhalten im Netzwerkbereich und da er sich bei iptables vordrängelt, bohrt er große Löcher in die Firewall. Mit nftables kann docker nichts anfangen.
Ansonsten würde ich da immer einen nginx als Proxy davor setzen, der sich um https kümmert, sonst ist der Port 443 für den einen Container verbraucht.
Ich setze als Alternative für Docker auf Podman. Hier kannst du die Container auch im User-Mode starten und hast damit auch weniger Sicherheitsprobleme, da Docker die Container immer als root startet.
Bei mir läuft homeassistant auf einem Pi4 als Container mit podman und einem nginx-Proxy direkt auf dem Pi. Und dazu noch der certbot für die SSL-Zertifikate.
Gruß Rico
Am 05.11.25 um 23:14 schrieb Andreas Oettel:
Hallo zusammen,
Ich benötige mal Eure Hilfe. Ich scheitere gerade am Grundverständnis, wo mein Problem liegt.
Ich habe einen Raspi 5. Der hängt an einem Telekomrouter und ist über einen DynDNS-Provider (Selfhost.de) ansprechbar.
Auf dem Raspi habe ich Docker drauf installiert. (Ich habe 0 Erfahrung damit und möchte mich damit beschäftigen.) Erstes Spielobjekt ist Nextcloud. (Ist für mich auch neu.) Dazu habe ich mir von "hub.docker.com" "nextcloud/all-in-one" runtergeladen.
Nächster Schritt war die zur Verfügung gestellte Installationsanleitung abzuarbeiten: https://nextcloud.com/blog/how-to-install-the-nextcloud-all-in-one-on- linux/ Die Konfigurationsseite habe ich zuerst von Intern aufgerufen https://127.0.0.1:8080
Beim Punkt 7 der Anleitung - Angabe der Domaine - war die Erfolgsstory auch schon beendet.
Wenn ich im Feld für die Domaine den Namen, über den der Rechner erreichbar ist, nenne wir ihn mal zum Beispiel raspi5.selfhost.eu, eintrage, kommt die Meldung das die Seite nicht erreichbar ist:
The domain is not reachable on Port 443 from within this container. Have you opened port 443/tcp in your router/firewall? If yes is the problem most likely that the router or firewall forbids local access to your domain. You can work around that by setting up a local DNS-server.
Ok! Das hängt mit dem Telekomrouter zusammen, dachte ich mir. Der bekommt es sicherlich nicht hin, Anfragen, die von intern kommen, sauber raus und dann wieder hinein zu routen. In der Datei /etc/hosts habe ich deshalb die interne IP vom Raspi eingetragen: 192.168.2.128 raspi5.selfhost.eu
(Im Telekomrouter gibt es eine Weiterleitung auf den Port 443 und Port 3478, wie in der Anleitung beschrieben)
Das hilft aber nicht. Die Fehlermeldung bleibt.
Ebenso hilft es nicht die IP's der Dockernetzwerke anzugeben (172.18.0.1; 172.17.0.1; 172.18.0.3).
---- Die IP vom Docker ist laut ifconfig ----
br-ae134de8761d: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 172.18.0.1 netmask 255.255.0.0 broadcast 172.18.255.255 inet6 fe80::58a0:89ff:fe51:5669 prefixlen 64 scopeid 0x20<link> ...
docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255 inet6 fe80::6458:deff:feea:4a47 prefixlen 64 scopeid 0x20<link> ...
---- Die Ausgabe zu "iptables-nft -L -n -v" ----
Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 5677 648K DOCKER-USER 0 -- * * 0.0.0.0/0 0.0.0.0/0 5677 648K DOCKER-FORWARD 0 -- * * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination
Chain DOCKER (2 references) pkts bytes target prot opt in out source destination 4 240 ACCEPT 6 -- !br-ae134de8761d br-ae134de8761d 0.0.0.0/0 172.18.0.3 tcp dpt:443 0 0 ACCEPT 6 -- !br-ae134de8761d br-ae134de8761d 0.0.0.0/0 172.18.0.2 tcp dpt:8443 8 424 ACCEPT 6 -- !br-ae134de8761d br-ae134de8761d 0.0.0.0/0 172.18.0.2 tcp dpt:8080 5 252 ACCEPT 6 -- !br-ae134de8761d br-ae134de8761d 0.0.0.0/0 172.18.0.2 tcp dpt:80 0 0 ACCEPT 6 -- !docker0 docker0 0.0.0.0/0 172.17.0.2 tcp dpt:9443 0 0 ACCEPT 6 -- !docker0 docker0 0.0.0.0/0 172.17.0.2 tcp dpt:8000 0 0 DROP 0 -- !docker0 docker0 0.0.0.0/0 0.0.0.0/0 0 0 DROP 0 -- !br-ae134de8761d br-ae134de8761d 0.0.0.0/0 0.0.0.0/0
Chain DOCKER-BRIDGE (1 references) pkts bytes target prot opt in out source destination 0 0 DOCKER 0 -- * docker0 0.0.0.0/0 0.0.0.0/0 605 32556 DOCKER 0 -- * br-ae134de8761d 0.0.0.0/0 0.0.0.0/0
Chain DOCKER-CT (1 references) pkts bytes target prot opt in out source destination 77 26152 ACCEPT 0 -- * docker0 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED 2137 309K ACCEPT 0 -- * br-ae134de8761d 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
Chain DOCKER-FORWARD (1 references) pkts bytes target prot opt in out source destination 5677 648K DOCKER-CT 0 -- * * 0.0.0.0/0 0.0.0.0/0 3463 313K DOCKER-ISOLATION-STAGE-1 0 -- * * 0.0.0.0/0 0.0.0.0/0 3463 313K DOCKER-BRIDGE 0 -- * * 0.0.0.0/0 0.0.0.0/0 83 11761 ACCEPT 0 -- docker0 * 0.0.0.0/0 0.0.0.0/0 2775 269K ACCEPT 0 -- br- ae134de8761d * 0.0.0.0/0 0.0.0.0/0
Chain DOCKER-ISOLATION-STAGE-1 (1 references) pkts bytes target prot opt in out source destination 83 11761 DOCKER-ISOLATION-STAGE-2 0 -- docker0 !docker0 0.0.0.0/0 0.0.0.0/0 2775 269K DOCKER-ISOLATION-STAGE-2 0 -- br-ae134de8761d !br- ae134de8761d 0.0.0.0/0 0.0.0.0/0
Chain DOCKER-ISOLATION-STAGE-2 (2 references) pkts bytes target prot opt in out source destination 0 0 DROP 0 -- * br-ae134de8761d 0.0.0.0/0 0.0.0.0/0 0 0 DROP 0 -- * docker0 0.0.0.0/0 0.0.0.0/0
Chain DOCKER-USER (1 references) pkts bytes target prot opt in out source destination
---- Ende ----
Habt Ihr eine Idee warum der Port 443 aus dem Container heraus als nicht erreichbar gilt?
Hat das manchmal mit dem Zertifikat zu tun? Kann es sein, dass die oben geschriebene Fehlermeldung eigentlich in die Irre führt, der Port offen ist, aber das Zertifikat die Kommunikation verhindert?
Wenn ich von außerhalb auf raspi5.selfhost.eu zugreife, kommt ein ERR_SSL_Protocol_ERR.
Wenn ich von intern auf raspi5.selfhost.eu zugreife kommt SSL_ERROR_RX_RECORD_TOO_LONG
Viele Grüße
Andreas
Hi,
irgendwie fehlt die Einstiegsmail auf der Liste..?
On Wed, 2025-11-12 at 10:05 +0100, Rico Koerner wrote:
ich würde dir sowohl bei der Nextcloud im speziellen, als auch allgemein von Docker abraten. Ich habe grundsätzlich nichts gegen Container, wenn sie vernünftig gebaut sind, aber die Konstellation ist kein guter Start.
Das ist nicht meine Erfahrung.
Die Nextcloud funktioniert im Container schlechter als standalone. Updates fordern mehr (manuelle) Nacharbeit, als einfach nur den Container zu aktualisieren. Wenn ein Plugin da drin nicht funktioniert ist die Fehlersuche komplizierter. All-in-one hab ich nie richtig zum laufen gebracht.
Das ist mit dem All-in-one tatsächlich auch meine Erfahrung. Es gibt aber noch den
https://hub.docker.com/_/nextcloud/
Der läuft wunderbar und ist deutlich einfacher aufgebaut. Das plus Reverse Proxy läuft bei mir seit langem stabil.
Docker (der Daemon) ist eine Zumutung, vollkommem irrationales Verhalten im Netzwerkbereich und da er sich bei iptables vordrängelt, bohrt er große Löcher in die Firewall. Mit nftables kann docker nichts anfangen.
Für iptables stimme ich da nicht zu. Es gibt die DOCKER-USER Chain, um Regeln zu erstellen. Man muss es halt nur wissen und beachten. Das funktioniert mit fail2ban oder ufw sehr gut.
Ansonsten würde ich da immer einen nginx als Proxy davor setzen, der sich um https kümmert, sonst ist der Port 443 für den einen Container verbraucht.
Oder Apache. Ansonsten ACK.
Gruß, Daniel
Hi Daniel,
Am 12.11.25 um 12:14 schrieb Daniel Leidert:
Hi,
irgendwie fehlt die Einstiegsmail auf der Liste..?
die hängt ja noch komplett an meiner ersten Antwort dran, falls sie bei dir abhanden gekommen ist.
Das ist mit dem All-in-one tatsächlich auch meine Erfahrung. Es gibt aber noch den
https://hub.docker.com/_/nextcloud/
Der läuft wunderbar und ist deutlich einfacher aufgebaut. Das plus Reverse Proxy läuft bei mir seit langem stabil.
Du hast Recht, das betrifft nur den AIO, die normale Version hatte ich auch eine Zeit lang im Einsatz. Allerdings waren die notwendigen Nacharbeiten mit occ nach Upgrades der Grund, das wieder in native Installationen zu migrieren. Der Container machte die Upgrades nur noch komplizierter. Ohne Container entfällt auch der zusätzliche Webserver im Container und macht das System dadurch schlanker.
Docker (der Daemon) ist eine Zumutung, vollkommem irrationales Verhalten im Netzwerkbereich und da er sich bei iptables vordrängelt, bohrt er große Löcher in die Firewall. Mit nftables kann docker nichts anfangen.
Für iptables stimme ich da nicht zu. Es gibt die DOCKER-USER Chain, um Regeln zu erstellen. Man muss es halt nur wissen und beachten. Das funktioniert mit fail2ban oder ufw sehr gut.
Ausgehend von einer funktionierenden Firewallkonfiguration, die nichts durchlässt was nicht explizit erlaubt ist, hat man nach dem Start eines Containers mit einem publishing Port diesen für die ganze Welt geöffnet, was ich nicht erwarten würde. Warum passiert das? Weil die Docker-Chains vor die vorhandenen Firewallregeln gestellt werden und diese damit umgeht. In der Docker-Chain werden dann Regeln erstellt, die eingehende Anfragen zum Container routen. Das ist ein schlechtes Standardverhalten. Ja, die User-Chain ist noch davor geschaltet und man könnte das dort auch wieder verbieten.
Die verschiedenen Docker-Netze sind besser gegeneinander abgeschirmt, als von der Außenwelt. Solange der Server im LAN steht, ist das alles nicht so dramatisch. Der Router verhindert schlimmeres. Es gibt leider auch keine Möglichkeit, die Regeln in der Docker-Config anzupassen, man kann es dort nur abschalten.
Wie sich das im Zusammenhang mit fail2ban einsortiert, kann ich nicht mehr sagen, da sich fail2ban sauber bei nftables in der inet-Chain integrieren lässt. Fail2ban löst aber auch nicht das ursprüngliche Problem, daß Ports ungefragt nach außen geöffnet werden.
Docker dagegen nutzt iptables-legacy und lässt sich damit nicht vernünftig in nftables integrieren. Ich möchte aber auf die Vorteile von nftables nicht mehr verzichten.
Zu ufw kann ich auch nichts sagen, aber Docker sagt selbst: (ufw) is a frontend that ships with Debian and Ubuntu, and it lets you manage firewall rules. Docker and ufw use firewall rules in ways that make them incompatible with each other. Quelle: https://docs.docker.com/engine/network/packet-filtering-firewalls/ Docker umgeht auch hier die eigenen Firewallregeln.
Ich konfiguriere das lieber direkt in der nftables.conf. Für iptables hab ich früher noch ferm benutzt.
Ansonsten würde ich da immer einen nginx als Proxy davor setzen, der sich um https kümmert, sonst ist der Port 443 für den einen Container verbraucht.
Oder Apache. Ansonsten ACK.
Oder irgendeinen Reverse-Proxy, je nach persönlichen Vorlieben.
GrußRico
lug-dd@mailman.schlittermann.de
-
Andreas Oettel -
Daniel Leidert -
Rico Koerner