Ich möchte Dropbox ersetzen mittels eines Ubuntu-Mini-Servers. Von der ganzen Sache habe ich aber leider keine Ahnunng und deshalb mittels YouTube und Google versucht zum Ziel zu kommen. Linux und Portainer mit Containern u.A. Nextcloud-AIO und Nginx-Proxy-Manager sind hinzugefügt aber nur bis Anmeldeseite geöffnet worden.
Einen Free-Account mit einer Domain bei ipv64.net ist vorhanden.
Nachdem ich mir die Youtube-Anleitungen zu: Free DynDNS, Einrichtung: Fritzbox DynDNS+ … und NGINX Proxy Manager - Reverse Proxy, Erklärung und Installation
mehrfach angesehen habe bin ich total verwirrt und mein Optimismus das ich einen Homeserver von außen erreichbar machen könnte, hat sich gemindert.
Mein erstes Problem: Im Video zum Nginx Proxy Manger wird für jeden Namen (in dem Beispiel: raspberry.deine-domain.de, pfsense.deine-domain.de, bitwarden.deine-domain.de) eine separate Domain benötigt? Dann ist der Free-Account voll ausgeschöpft?
Damit komme ich gleich zum zweiten Problem: Trage ich alle drei Domainnamen in der FritzBox unter DynDns ein oder sollte dort nur „ipv64.de“ stehen?
Ich bin für jeden Hinweis, der mir weiter hilft dankbar.
Der Anfänger sollte mal mit den Basics beginnen.
Welche Art Internetanschluss hat der Anfänger (Dual Stack, DS-Lite, CGNAT)?
Und wenn der Anfänger schon mal dabei ist, sollte er auch verraten was er am Internetanschluss als Router / Firewall hat.
PS: How to install the Nextcloud All-in-One on Linux wäre die offizielle Anleitung zur Installation von Nextcloud AIO. Allerdings ohne Anpassungen auch nur passend für Dual Stack, nicht aber DS-Lite / CGNAT
Eine Domain reicht völlig, z.B. deinedomain.ipv64.de. Die aktualisierst du per DDNS-Update.
Die restlichen Namen erzeugst du durch weitere CNAME-Records mit Präfix, z.B. nextcloud.deinedomain.ipv64.net die auf die Hauptdomain zeigen, oder halt anderswo hin. Oder du aktivierst einfach die Option „Set Wildcard automatically“, dann wird alles, also z.B. irgendwas.deinedomain.ipv64.de auf so aufgelöst.
Moin @Benares, deine Hinweise sind zwar richtig, nutzen aber nichts, wenn der TS (@Max_Malzmann) DS-Lite / CGNAT hat und auch nur bedingt etwas wenn der DNS-Rebind-Schutz im Router voreingestellt ist.
Meine vor diesem Hintergrund gestellten Fragen werden vom TS aber leider nicht beantwortet.
1 Like
Entschuldigung, aber ich habe nicht immer die Zeit um mich um den Computer zu kümmern.
Zu den Fragen: Der Anschluß ist bei Vodafone/Kabel Deutschland und es wird ein DS-Lite-Tunnel verwendet. Der Router ist eine FritzBox 6670. Außer einem Windows PC ist ein Ubuntu-Linux-Server angeschlossen, der im Netzwerk als miniserver mit der Netzwerkadresse 192.168.178.40 erscheint. . Auf der Fritzbox sind hierfür (nur IPV6) die Ports 80 und 443) freigegeben. Die Windows Firewall habe ich nicht angefaßt. Auf dem miniserver habe ich die Ports freigegeben.
Eine Domain habe ich aktiviert und Healthchecks (ping) sind jetzt auch im grünen Bereich.
Um Nextcloud AIO und Ngnix wollte ich mich kümmern, wenn ich weiß was bei IPV64 zu regeln ist.
Wie ich bereits erwähne setzt Nextcloud AIO Dual Stack voraus. Einer der Gründe:
- Doker Container supporten per default kein IPv6. Man kann es aktivieren. Das muss m.E. aber bereits vor der Installation von Nextcloud AIO passieren. Hinweise dazu finden sich in der Suchmaschine deiner Präferenz.
Bei allen Fitten ist per default der DNS-Rebind-Schutz im Router aktiviert. Er lässt sich auch nicht deaktivieren. Man kann nur Ausnahmeregeln für diesen festlegen. Ohne eine solche Ausnahmeregel scheitert die Prüfung der Nextcloud AIO ob sie von extern unter der gewählten Domain erreichbar ist. Das Setup bricht dann an der Stelle ohne Erstellung von Let’s Encrypt-Zertifikaten ab.
Du benötigst nur EINE Domain. Du kannst Domain-Präfixe verwenden, wie z.B. nextcloud.deineDomain.ipv64.net oder rpi.deineDomain.ipv64.net. Da du ohnehin nur Ipv6 hast (DS-Lite) benötigst du keinen Reverse Proxy.
Nein, denn du verwendest ja dann Domain-Präfixe zu EINER Domain.
AIO ist zwar leicht zu installieren, die damit verbundenen zahlreichen Docker Container für Anfänger aber kaum zu durchschauen. Eine einfachere Alternative ist Nextcloud-SNAP. WIll man etwas lernen und verstehen, was man warum macht, nimmt man einen sog. Bare-Metal Installation. Eine empfehlenswerte ist:
Dann musst du wohl über IPv6 gehen und brauchst mehrere Namen die auf die IPv6 (GUA, meist die mit ff:fe in der Adresse) deines Linux-Servers zeigen.
Mein Vorschlag wäre:
Leg einen AAAA-Record, z.B. mit Präfix „meinserver“ und trag hinten nur den Interface-Identifier ein. Der sich ändernde IPv6-Präfix kommt durch das DDNS-Präfix-Update mit dazu.
Für die restlichen Namen „nextcloud“ usw. leg weitere CNAME-Records an, die auf den meinserver-Record zeigen.
Äh - nein !!! Jedenfalls nicht wenn die restlichen Server auch https/http verwenden. Auch bei IPv6 gilt pro IPv6-Adresse kann nur einmal ein Port (wie z.B. TCP 80/443) verwendet werden. Geht es hingegen um andere Ports, wie z.B. TCP 22 (ssh) kann derselbe Präfix verwendet werden.
Will @Max_Malzmann zwei oder mehrere Webserver auf einem Mini-Rechner laufen haben, braucht er wieder einen Proxy, aber für IPv6. Ich weiß nicht ob man sich als Anfänger daran wagen sollte.
Meine Ansatz wäre dann die Virtualisierung mittels QEMU/KVM. Richtig konfiguriert (also Macvtab- oder Bridge-device) als Virtuelle Netzwerkschnittstelle. hat dann jede VM eine eigene IPv6-Adresse (GUA) und ein Proxy ist überflüssig.
Zudem kann es so keine Konflikte hinsichtlich zu erfüllender Abhängigkeiten zwischen den Abhängigkeiten unterschiedlicher Server-Software geben.
Aber ganz oben steht doch schon, dass ein NPM im Einsatz ist. Die Frage war doch, wie er an mehrere Namen für die IPv6 des NPM-Hosts kommt, damit dieser die Anfragen dann weiterverteilen kann, oder?
Da ist zuvor mehr zu tun.
- prüfe ob deine FB den Clients IPv6-GUA’s per DHCPv6-Server zuweist
- prüfe ob dein Ubuntu-Server eine IPv6-GUA zugewiesen bekommt
- deaktiviere in der FB die Zuweisung von ULA’s
- nutze die Update-URL Mit AVM Fritzbox IPv6-Prefix Updaten aus den Anleitungen.
- richte für den Ubuntu-Server einen Domain-Präfix ein, auf Basis eines AAAA-Records, entweder im Format Interface-ID oder EUI-64 MAC ein
(im Bild blau markiert)
Damit wären dann die Voraussetzungen geschaffen, diesen Server von extern per IPv6 zu erreichen.
Soll er auch von intern unter seiner Domain erreichbar sein (erforderlich bei AIO für Let’s Encrypt) muss in der FB auch auch noch eine Ausnahmeregel für den DNS-Rebind-Schutz definiert werden.
Nachtrag:
Lektüre zu GUA, ULA, etc. denn ohne Grundwissen zu IPv6 wirst du nicht weit kommen.
Cloudrouter dazwischen und dann servertechnisch alles per ipv4 und dann ist ruhe.
Oder erst alles per IPv6 sauber einrichten, und dann CDN und den CDN Reverse Proxy für Zugang per ipv4 einrichten.
Dann wäre der Nextcloud-Server zumindest auch dann noch per ipv6 erreichbar, wenn die ipv64-Dienste mal kurzzeitig unerreichbar sind, wie vor ca. einem Jahr, als ipv64 über mehrere Wochen hinweg das Ziel von DDoS Angriffen war.
Ich finde die Lösung mit einem eigenen NPM im Heimnetz besser. Nur unterstützt der wohl leider nicht nativ ipv64.net für die Erstellung/Verlängerung von LE-Zertifikaten.
Macht die Angelegenheit aber nicht unkomplizierter, zumindest nicht bei AIO. Im Gegenteil!
Bei Nextcloud AiO (Docker) hinter einem Proxy benötigt man zusätzlich Split-DNS. Warum?
- Der interne DNS-Server muss dafür nun einen DNS-Record vorhalten, der die Domain (z.B. „cloud.meine.domain.de“) auf die IP des Hosts mit dem Proxy verweist.
- Der Installer von Nextcloud AiO „sucht“ bei der Ersteinrichtung nach der entsprechenden Domain. Ist vorab kein Split-DNS Eintrag im System vorhanden, scheitert die Installation. Grund hierfür ist, dass man in dem Router i. d. R. HTTP & HTTPS per Portweiterleitung auf den Proxy weiterleitet. Ergo scheitert die Kommunikation auf Port 443.
Die einfachste Lösung für das Problem ist dann eine Modifizierung der /etc/hosts auf dem Host, welcher Nextcloud AiO als Container vorhält
Auf diesen Umstand sollte man einen Anfänger dann aber auch hinweisen, wenn man die Vorzüge von NPM im Heimnetz preist.
Geht bei mir über DnsMulti als DNS Provider.
dns_multi_provider = ipv64
IPV64_API_KEY = <Dein-IPv64-API-Key>
## oder mittels KEY file:
#IPV64_API_KEY_FILE = /data/.ipv64 # <-- hier steht dann dein API Key drin
Interessant, danke für die Info.
1 Like
Danke für die Info für mich ein Grund mehr, Nextclud ins VPN zu packen bzw nur mit VPN-Verbindung erreichbar zu haben.
Na ja, bei einer privaten Nextcloud geht das. Aber ich reise sehr viel, und will meine Reise-Bilder mit anderen teilen, oder auch andere was hochladen lassen.
Von einer Nextcloud auf einem internen Host halte ich nicht viel, mein Heimnetz bleibt zu. Deshalb hab ich mir schon seit längerem einen kleinen vServer in der Cloud angeschafft mit einer eigenen Domain bei Netcup und betreibe solche Dinge dort, mit docker, NPM & Co läuft das recht easy, und ipv64 verwende ich nur als CNAME-Lieferant für andere Dinge.
Auch da kann man recht leicht einen Wireguard-Tunnel ins eigene Heimnetz anlegen, wenn das notwendig sein sollte, und z.B. Immich auf dem vServer mit Daten aus Heimnetz betreiben. Man muss natürlich wissen, was man tut, damit man sein Heimnetz nicht auf diesem Weg ins Internet stellt.
Eins ist offensichtlich. Die Ansprüche an eine Cloud sind höchst unterschiedlich. @Max_Malzmann möchte zunächst nur Dropbox ersetzen. Für @Benares ist das hochladen von Fotos und das Teilen dieser mit anderen wichtig.
Mir z.B. war es von Anfang an ein Anliegen mich weitgehend von den Google-Diensten zu lösen. Also vor allem auch bei den personenbezogenen Daten, wie Adressbüchern, Kalendern, etc. Dafür sollte ein NC-Server nicht hinter einem VPN verborgen werden, denn dann kann das Smartphone nur bei bestehender VPN-Verbindung oder im heimischen WLAN synchronisieren.
Daher sollte man vor dem Aufsetzen eines NC-Servers am besten mal ein Anforderungsprofil erstellen, damit die am Ende gewählten Konfiguration auch zu dem passt was man eigentlich benötigt.
Vpn-Tunnel nach Hause ist am Phone immer an wenn draußen. Aber stimmt klar werden was man will und welcher Weg für einen passt muss jeder selber.
