Die ownCloud / Nextcloud im eigenen Netzwerk aus dem Internet erreichen

Hier mal ein kleiner Leitfaden, wie man die im eigenen Netzwerk betriebene ownCloud von außen erreichen kann. Ich wollte das schon lange mal auf digitales Papier bringen, habe es aber irgendwie immer wieder vergessen. Mir ist es wieder eingefallen, als ich openSUSE 13.2 auf den Mac Mini installiert habe und dort eben auch den Synchronisations-Client der ownCloud, der seit kurzer Zeit als Version 1.7.0 mit Verbesserungen verfügbar ist. Das Problem ist, dass es an dieser Stelle so viele Optionen gibt, dass man die alle unmöglich abfackeln kann. Es gibt endlos viele Router-Server-IP-Adress-Kombinationen. Ich versuche, das Thema so allgemein wie möglich und trotzdem so verständlich zu halten, dass man am Ende weiß, was man tun soll.

Um was geht es?

Solange ich mich in meinem eigenen Netzwerk befinde, ist die intern installierte ownCloud natürlich erreichbar – notfalls via IP-Adresse direkt. Sobald ich aber unterwegs bin, habe ich keinen Zugriff mehr darauf. Mein Notebook kann sich also nicht synchronisieren oder Dateien sichern, neue Kontakte oder Kalendereinträge würden nicht synchronisiert und so weiter.

Man könnte nun sagen: “Ich warte einfach, bis ich wieder zuhause bin.” Stimmt, könnte man, muss man aber nicht. Wobei das ehrlich gesagt die sicherste Lösung ist, da die ownCloud eben von außen nicht erreichbar.

Verwendet man allerdings ein selbst unterzeichnetes Zertifikat und eine HTTPS-Verbindung, dann sollte es recht sicher sein. Weiterhin kann man sich noch komplette Fantasie-Namen ausdenken -> Security by Obscurity. Kommen wir später noch dazu.

(Hinweis: Eine Server-Installation der ownCloud und wie man ein selbst erstelltes Zertifikat erstellt, gibt es zum Beispiel in einem Artikel von mir bei TecChannel.)

Wie sieht das Szenario aus?

Ich habe hier einen ownCloud-Instanz auf meinen Server laufen, der die IP-Adresse 192.168.100.3 hat. Von meinem Service-Provider bekomme ich eine dynamisch IP-Adresse zugewiesen, die ändert sich also laufend. Nun befinde ich mich aber nicht in meinem internen LAN, will aber trotzdem auf mein Netzwerk Zugriff. Aus diesem Grund müsste ich die IP-Adresse wissen, die mir mein Service-Provider im Moment zugewiesen hat. Ohne dieses Wissen geht gar nichts. Wir benötigen also eine dynamische Namensauflösung.

Scratch möchte auf seine ownCloud zugreifen, kann die IP-Adresse des Service-Providers unmöglich erraten (man verzeihe mir meine krude Illustration)

Dynamisches DNS (DDNS)

Dynamisches DNS macht folgendes. Im internen LAN läuft irgendwo ein Client, der einem Provider für dynamisches DNS meine derzeitige IP-Adresse übermittelt, die ich vom Internet-Provider zugewiesen habe. Wie der Client das genau macht, ist irrelevant – er tut das einfach.

Es gibt Router, die bereits einen DDNS-Client integriert haben. Man holt sich also ein Konto beim entsprechenden Anbieter und trägt die Anmeldeinformationen ein. Mein oller Netgear-Router würde DynDNS .org zur Verfügung stellen. Die wollen allerdings 25 US-Dollar pro Jahr. Es gibt auch andere Anbieter, wie zum Beispiel noip.com. Bei denen gibt es ein freies Angebot, das man alle 30 Tage erneuern muss. Wer wie ich ein Synology sein Eigen nennt, der bekommt von der Firma kostenlos eine dynamisch IP-Adresse. Einfach mal nachsehen. Ich verwende das Synology, weil der Service dabei und einfach einzurichten ist.

Wer nun Security by Obscurity betreiben möchte, der wählt einen komplett wilden Namen. Ich habe einfach mal einen Passwort-Generator genommen und für den weiteren Beitrag nehme ich als Beispiel: e3httv3nc74jpdt.myds.me (myds.me ist ein Synology-Service und NEIN, das ist nicht meine echte DDNS-Adresse).

Wie gesagt, ist es egal, welcher Client aus dem internen LAN dem DDNS-Provider die IP-Adresse mitteilt.

Nun erreicht Scratch zwar den Router, dieser weiß aber nicht wohin mit der Anfrage …

Port Forwarding

Aus dem internen Netzwerk erreiche ich die ownCloud wie gesagt via https://192.168.100.3/owncloud. Das Ziel ist es nun, sie von außen via https://e3httv3nc74jpdt.myds.me/ownlcoud ansprechen zu können. HTTPS geht bekanntlich via Port 443. Will ich nun aber auf die https://…myds.me zugreifen, weiß der Router nicht, welcher Rechner im internen Netzwerk diese Anfrage beantworten soll.

Hier kommt eine Technik ins Spiel, die sich Port Forwarding nennt. Bei manchen Routern heißt das auch Services oder Firewall-Regeln und so weiter. Im Endeffekt teilt man den Router hier mit:

• Hör mal, wenn hier einer extern via 443 reinkommt, dann leite den doch intern auf 192.168.100.3 (in meinem Fall) um.

Ist das geschafft und ich gebe nun https://e3httv3nc74jpdt.myds.me/ownlcoud ein, dann geht die ownCloud-Seite auch tatsächlich schon auf.

Scratch kommt nun auf seine ownCloud-Instanz aus dem Internet. Eine Hürde ist aber noch zu nehmen …

ownCloud: Trusted Domain / vertrauenswürdige Domäne hinzufügen

Die ownCloud sagt mir nun:

• Hör mal, unter der Domäne hast Du mich aber nicht installiert. Da stimmt was nicht. Ich blocke das erst mal und der zuständige Administrator soll die Domäne e3httv3nc74jpdt.myds.me erst mal in die Konfiguration eintragen, damit dieser vertraut wird.

Da ich zufällig Administrator meiner eigenen ownCloud bin (wer hätte es gedacht), kann ich das natürlich erledigen. Ich begebe mich zu meiner mit Linux bestückten ZBOX (gehen, Turnschuhadministration pffff, ssh natürlich) und editiere die Datei config.php in meiner ownCloud-Installation. Bei mit ist das /var/www/owncloud/config/config.php.

Dort findest Du einen Parameter, der sich trusted domains nennt. Hier fügen wir einfach einen zweiten hinzu. Da das Ding ein array ist, fängt das Ding natürlich mit 1 => an. Das nachfolgende Bild visualisiert, was gemeint ist.

Nachdem die Domäne nun als vertrauenswürdig hinterlegt ist, funktioniert auch der Zugriff von außen.

Zusammengefasst

Hätte ich nun einfach geschrieben:

• DDNS
• Port Forwarding
• Trusted Domain

hätte ich mir das ganze Gelaber sparen können, oder? … 😉

Aufpassen muss man nun noch, dass man alle internen Links von vorher auf die extern eingerichtete DDNS-Domäne ändert.

Stromsparende Cloud, die immer erreichbar ist

Wenn man alleiniger Nutzer ist, dann kann man die ownCloud recht annehmbar auf einem Raspberry Pi betreiben. Das Gerät braucht extrem wenig Strom und man hätte immer Zugriff auf seine Daten und diese befinden sich unter eigener Kontrolle.

Nette Pi-Konstellation

Suchst Du ein VPN für den Raspberry Pi? NordVPN* bietet einen Client, der mit Raspberry Pi OS (32-Bit / 64-Bit) und Ubuntu für Raspberry Pi (64-Bit) funktioniert.

---

---