Hallo, ich habe meine Nextcloud auf die Ports 4433 (SSL) und 808 gelegt. Wenn ich meine nextcloud über die dyndns Adresse aufrufe mit dem Port (mydyndns.com:4433), so funktioniert die Weiterleitung. Das Letsencrpt Zertifikat abholen scheitert allerdings immer am Port 80. Deswegen habe ich versucht, den Port 80 auf 808 weiterzuleiten in der Fritzbox, aber das geht nicht. Ich bekomme eine Fehlermeldung. Habt ihr hier einen Tipp für mich?
Hallo @androidin
Jup. Nutze einfach die Ports 80/443. Obskure Ports zu verwenden macht dir das Leben nur schwerer und bringt im Gegenzug wenig bis gar keine zusätzliche Sicherheit.
Falls du mehrere Dienste/Server mit unterschiedlichen internen IP Adressen hostest und deshalb andere Ports für die Nextcloud verwenden möchtest, suche mal nach dem Stichwort “Reverse Proxy”.
…und falls es aus was für Gründen auch immer gar nicht anders gehen sollte, hilft dir das evtl weiter:
https://docs.nextcloudpi.com/en/how-to-get-certificate-with-letsencrypt-using-dns-to-verify-domain/
Ich kann @bb77 auch nur zustimmen. Verwende unbedingt 80/443 von außen auf deiner Fritzbox und gerne auch lokal auf deinem Nextcloud Server.
Was spricht dagegen? Wie gesagt die Sicherheit kann es nicht sein. Ich weiß auch nicht, ob Lets Encrypt die Standard-Ports verlangt oder nicht.
Kommt auf den “Challenge Type” drauf an. Für die vollautomatische Variante via HTTP-01 Challenge" muss Port 80/443 verwendet werden.
https://letsencrypt.org/de/docs/challenge-types/
Alternativ kann wie schon gesagt die DNS Challenge verwendet werden. Dort ist aber jenachdem manuelle Arbeit bzw. Skripting involviert. Oder man kann ein Produkt wie Traeffik oder NGINX-Proxy-Manager oder die HA-Proxy Implementation von pfSense (Die letzten beiden haben ein WebGUI für die Konfiguration) als Reverse Proxy verwenden. Und man braucht einen DNS-Anbieter, der API Zugriffe für die automatische Erneuerung der Zertifikate anbietet.
https://letsencrypt.org/de/docs/challenge-types/#dns-01-challenge
Danke für die Details. Ich habe wieder was gelernt. Am besten @bb77 nennt erst mal Gründe für 4443/808. Meistens sind die Gründe für diese komischen Ports (wodurch im übrigen die URLs auch doof aussehen) unbegründet.
Joa sehe ich auch so 
DNS-Challenge hat andere Vorteile. Man kann z.B. Wildcard Certs ausstellen llassen und/oder auch rein interne Dienste damit absichern, die nicht aus dem Internet erreichbar sein müssen. Wildcard Zertifikate haben auch den Vorteil, dass die Hostnamen dann nicht öffentlich bekannt sind. Ist vorallem für Firmen interessant, die nicht wollen, dass die ganze Welt die Namen ihrer internen Dienste kennt.
1 Like
Danke für eure Antworten. Ich hatte es am Anfang versucht, die Standard Ports zu nutzen, aber es haben mehrere Dinge auf den Ports gelauscht. Einige davon, wie z. B. pihole habe ich umverdrahtet. Beim Deconz-Adapter des ioBroker ist mir das allerdings nicht gelungen. Der lauscht immer auf 443.
Edit: Ausserdem wollte ich so wenige Ports offen lassen wir nötig. 80 habe ich in der FritzBox geschlossen.
Edit2: Mein NAS lauscht auch auf den (externen) Port 443. Das könnte dann von aussen auch zu Zugriffsproblemen führen, oder?
Läuft der auf dem gleichen Gerät, wie die Nextcloud? Falls ja hättest du auch intern ein Problem. Grundsätzlich kann an einer IP Adresse pro Port nur ein Dienst laufen. Da gibt es nicht wirklich eine elegante Lösung. Ausser es handelt sich um mehre Websites. Diese kannst du via mehrere “virtuelle Hosts” separieren. Bringt aber eine Anwendung ihren eigenen Webserver mit, funktioniert auch das so nicht mehr.
Wenn die Geräte intern mit verschiedenen IPs laufen, sprich auf eigenen Geräten und/oder in eigenen VMs, heisst die Lösung Reverse Proxy.
Weiter stellt sich die Frage, ob wirklich alle diese Dienste direkt von ausserhalb erreichbar sein müssen. Gerade bei Management Interfaces wie bei derjenigen des NAS oder evtl. auch die des IOBrokers, ist es eigentlich nicht “Best Practice”, diese direkt ins Internet zu stellen. Hier könntest du dir überlegen einen Wireguard oder OpenVPN Server aufzusetzen und dich dann so auf diese Dinge zu verbinden.
Der ioBroker hat keinen geöffneten Port nach aussen. Dass der Deconz-Adapter auf 443 lauscht, hatte ich vorher gar nicht bemerkt. Der (ext. Port 443) wird auch nicht an den Raspi geleitet (momentan), der ist mit dem NAS verbunden.
→ Läuft der auf dem gleichen Gerät wie die Nextcloud
Ja, bei mir läuft auf dem Raspi: ioBroker, pihole, unbound und nextcloud
Ich kenne ioBroker nicht. Aber wenn der einen Dienst bereitstellt, der auf Port 443 lauscht, wird das mit Let’s Encrypt und Certbot für den Apache bzw die NC nicht funktionieren. Und selbst wenn du es irgendwie via DNS Challenge oder manuell hinkriegst der NC ein Zertifikat zu spendieren, wirst du Probleme kriegen, sobald du versuchst Apache auf Port 443 zum laufen zu kriegen.
Die einzige Möglichkeit wäre, den Virtuellen Host für NC auf z.B. Port 444 zu setzten und dann im Router Port 443 zu Port 444 forwarden. Dann funktioniert aber die automatische Let’s Encrypt HTTP-Challenge via Certbot nicht und du müsstest das Zertifikat manuell via DNS-Challenge installieren (siehe Anleitung in meinem vorherigen Post). Weiter kannst du dann den ioBroker Dienst von ausserhalb nicht mehr via Port 443 erreichen, falls das gewünscht/nötig wäre.
Long story, short:
Ich würde mir entweder einen speparaten Raspi für ioBroker bzw. Nextcloud zulegen oder du installierst alles mit Docker in Verbindung mit einem Reverse Proxy.
Ich habe mal ganz kurz nach ioBroker gesucht. Vielleicht kannst du besser ioBroker auf einen anderen Port laufen lassen. Vielleicht kannst du - selbst wenn du von außen zugreifst - auf ein Lets Encrypt - Zertifikat verzichten. Vor allen wenn du das alleine nutzt geht das wohl eher als bei Nextcloud darauf verzichten zu wollen (z. B. Teilen mit Dritten).