Die ownCloud im eigenen Netzwerk aus dem Internet erreichen

8 November 2014 4 Kommentare Autor: Jürgen (jdo)

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)

Scratch weiß die IP-Adresse nicht

Scratch weiß die IP-Adresse nicht

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 …

Nun ist Scratch schon einen Schritt weiter - nur der Router weiß nicht, wohin mit der Anfrage

Nun ist Scratch schon einen Schritt weiter – nur der Router weiß 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 …

Endlich kann Scratch seine ownCloud-Daten von überall erreichen

Endlich kann Scratch seine ownCloud-Daten von überall erreichen

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.
Keine vertrauenswürdige Domäne!

Keine vertrauenswürdige Domäne!

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.

In die config.php muss die Domäne als vertrauenswürdig aufgenommen werden

In die config.php muss die Domäne als vertrauenswürdig aufgenommen werden

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

Du kannst gerne Deinen Senf zu diesem Beitrag geben: Hier geht es zu den Kommentaren




Schreiben macht durstig! Eine kleine Erfrischung kann daher nie schaden. Wem dieser freie Artikel gefallen hat, der darf mir gerne einen frisch gezapften Hopfen-Tee ausgeben (Paypal - der Spenden-Knopf
oder bitcoin - Adresse: 1NacVNwcLLePUVv8uSafu5Ykdwh8QyDfgK). Ich freue mich über jede noch so kleine Spende. Vielen Dank und Prost!
 Alle Kommentare als Feed abonnieren

4 Kommentare zu “Die ownCloud im eigenen Netzwerk aus dem Internet erreichen”

  1. Michael sagt:

    ...oder die Owncloud liegt auf dem heimischen Server und bleibt von außen nicht erreichbar.

    Wenn ich was synchronisieren muss, wähle ich mich per VPN ein.

    • jdo sagt:

      Kann man natürlich machen, auch dann brauche ich das Port Forwarding und DDNS ... 🙂

      Ich habe aber keine Lust, auf jedem neuen Gerät, Smartphone, Tablet und so weiter einen VPN-Client zu installieren. Es geht ja nicht nur um die Daten. Trage ich etwas in den Kalender ein oder erstelle einen neuen Kontakt, will ich mich nicht erst via VPN einwählen müssen, dass die Daten synchronisiert werden.

      Aber ich gebe Dir Recht, dass dieser Punkt diskussionswürdig ist. So ist es auf jeden Fall besser als würden die Daten bei Google, Dropbox oder sonstwo landen.

  2. MichaelM sagt:

    Vielen Dank Jürgen für diesen Beitrag!
    Ich hatte ein paar Tage frei und mich endlich auch an mein eigenes OwnCloud-Experiment gewagt 🙂 Da kam deine Anleitung wie gerufen.

    Für mich als Neuling waren auch die beiden Artikel von Rojtberg ganz nützlich:
    http://www.rojtberg.net/687/secure-owncloud-setup
    http://www.rojtberg.net/711/secure-owncloud-server

    Und am Schluss den Server noch prüfen mit:
    https://www.ssllabs.com/ssltest/index.html

    Auf den Androiden nutze ich FolderSync Lite und da gibt's seit dem Upgrade auf OwnCloud v7.0.3 eine fiese Stolperfalle:
    https://forum.owncloud.org/viewtopic.php?f=29&t=23983
    https://github.com/owncloud/core/pull/12154

    Damit WebDAV Clients wieder auf OwnCloud zugreifen können muss als Work-around (bis v7.0.4 erscheint) der Port in der Trusted Domain mit angegeben werden 😮
    Z.B. so:
    0 => 'x.y.z'
    1 => 'e3httv3nc74jpdt.myds.me'
    2 => 'e3httv3nc74jpdt.myds.me:443'

    😉

  3. Daniel sagt:

    Halte diese Art der Freigabe für sehr gefährlich. Der Webserver ist direkt aus dem Inet erreichbar und kann leicht via Portscan gefunden werden. Ein winziger Bug im Server, im SSL-Modul oder in Owncloud selbst und zack - deine cloud war mal own 😉

    Ich selbst habe sie hinter nem VPN- Gateway stehen. Will ich syncen, muss ich mich einwählen. Dauert ca. 5 Sekunden 😉

    Gruß

Antworten