Off SIte Backup / VPN Verbindung

  • Liebe Foristen, folgende Fragestellung:


    Ich habe zwei QNAP mit aktueller Firmware und möchte ein Off Site Backup realisieren. Was ich bisher erreicht habe:

    Ich habe auf meinem NAS in meiner Wohnung einen OpenVPN Server laufen, einen DYNDNS Server den das QNAP updated und den Port weitergeleitet. Ich komme auch vom Handy und von meinem Notebook auf die Kiste mit der lokalen IP (192.168.0.2).


    Das entfernte NAS hat den RTRR Server laufen für das Backup und ist der VPN Client (lokale IP 192.168.2.2). Der Plan ist nun dass das entfernte NAS zu einem definierten Zeitpunkt hochfährt, den VPN-Tunnel öffnet und das loklae NAS dann den Backup Auftrag startet (ne viertel Stunde später, wenn der Tunnel also stehen sollte).


    Tatsächlich funktioniert das aber irgendwie nicht. Die Verbindung wird vom entfernten NAS aufgebaut, das sehe ich in den Verindungsprotokollen aber irgendwie ist das NAS vom lokalen aus nicht erreichbar. Welche IP muss der entfernte Speicherplatz denn haben? 192.168.2.2 oder die 10er Adresse vom Tunnel, beide werden irgendwie nicht gefunden und das NAS fragt ob beim entfernten NAS denn der RTRR Server läuft, was definitiv der Fall ist. Lokal ist das Backup problemlos gelaufen.


    kann einer helfen?

    Grüße

  • VPN auf dem NAS mit Portweiterleitungen ist unsicher (siehe Artikel von Mavalok2, schade dass ich ihn mal wieder nicht zur Hand habe).


    Bekommt dein Backup NAS / Client denn immer die gleiche IP aus dem VPN Pool zugewiesen? Dann kannst du die "10.x.x.x." IP nehmen. Sobald aber eine andere IP zugewiesen wird ist es vorbei. Soweit ich das sehen kann, ist das bei Qnap nicht weiter festlegbar.


    Der wie ich finde schickere Weg wäre es, die LAN IP zu verwenden (192.168.2.2).Dazu musst du am Quell NAS aber eine entsprechende Route anlegen, die besagt, dass Anfragen an 192.168.2.2 an das VPN gateway geroutet werden sollen. Das geschieht beim Virtual Switch unter Routen. Dann müsste das laufen, mit dem bitteren Beigeschmack dass aufgrund der Portfreigaben bald beide NAS unter der Kontrolle eines Bösewichts sein könnten...

  • Vielen Dank das werde ich versuchen. Naja aber die Hürden mit VPN sind ja schon höher als mit allem anderen oder nicht?


    ein Site zu Site VPN ist leider mit den Routern nicht möglich...

    Oder welche andere Möglichkeit gäbe es noch?

  • Für deinen (prinzipiell sehr guten) Plan gibt es glaube ich keine andere / bessere Lösung...


    Was meinst du mit

    Naja aber die Hürden mit VPN sind ja schon höher als mit allem anderen oder nicht?

    ?

    Dass es sicherer ist als die Freigabe direkt über das Internet verfügbar zu machen?

    Da mag nen Hauch Wahrheit dran sein, das NAS ist aber dennoch massiven Gefahren ausgesetzt, aber da wissen hier andere besser bescheid, wie und wo und was genau passieren kann, bzw. wie die Schwachstellen in welchem Szenario genau aussehen. Mir reicht es zu wissen, dass es gefährlich ist, wie genau das ausgenutzt werden kann ist mir eigentlich egal ;)

  • Hier hängt die Sicherheit an der Implementierung der OpenVPN Server auf den terminierenden Endgeräten.


    Da es sich hier um eine QNAP Software handelt und Software von diesem Hersteller in der Vergangenheit schon ein paar mal effektiv über Bots angegriffen und übernommen worden sind, kann man von einem höheren Risiko ausgehen, als wenn man das über einen VPN Router/Firewall terminiert.


    Mir war es die Datensicherheit wert und so gab es ein paar Hardware Firewall Appliances + Modems und der Tunnel steht nicht nur dem NAS zur Verfügung.

    Dank Firewall kann ich das bei Bedarf auch granular Regeln.


    Vor allem läuft so eine Firewall mit eine stabel Version meist über Jahre stabil, setzt man sogar HA ein, dann sind Uptimes über Updates hinweg möglich bis zum Austausch der Geräte.

    QTS hat gute und schlechte Updates, bei einigen kann man bedenkenlos updaten, bei anderen ist hinterher nur ein bisle was put bei anderen auch bisle mehr und bei einigen muss man sogar ein Downgrade machen. Was teilweise funktioniert, teilweise aber auch nicht.


    Es kann bei dir also funktionieren, wenn du rechtzeitig auf neuere QTS und App Versionen dann sogar lange ohne in ein Sicherheitsproblem zu laufen. Aber es kann auch nächste Woche um deine System geschehen sein.

    Hoffe du hast noch ein offline Backup für den Notfall.


    Ich stufe das Risiko als mittel bis gering ein, bei einer Hardware FW gehe ich dagegen von einem sehr geringem Risiko ein. Wenn man hier was gescheites einsetzt ist das sogar sehr sehr gering, da die Kisten gut getestet und reviewed werden.


    Wie immer, absolute Sicherheit wird man nie erreichen, aber letztes kommt für meine Bedürfnisse da schon sehr sehr nahe dran!

  • Okay, das mit den Routen habe ich gefunden.

    Mir ist allerdings nicht ganz klar was ich eingebe :-/

    Ziel wäre ja 192.168.2.2

    Gateway? Wie ist die Adresse vom VPN Adapter? Die muss ich da eintragen oder


    Metric? Weiß ich garnix mit anzufangen :(


    Vielen Dank und Grüße

  • Ziel wäre ja 192.168.2.2

    korrekt, oder optional das gesamte Netzwerk 192.168.2.0 falls der QNAP mehrere Geräte erreichen soll.

    Lass es genau erstmal bei der 192.168.2.2

    Gateway? Wie ist die Adresse vom VPN Adapter?

    Das ist Dein VPN Server, vermutlich die 10.8.0.1

    Das ist glaube ich auch bei QNAP konfigurierbar und kannst Du bei den VPN Server Einstellungen einsehen.

    Metric? Weiß ich garnix mit anzufangen

    Damit wird bestimmt, welche Route bevorzugt verwendet werden soll, wenn mehrere Einträge für das Ziel (-Netz) vorhanden sind. QNAP würde hier niedrigere Werte bevorzugen. Ich kenne die mögliche Range nicht und würde hier einfach eine 5 eintragen :S

  • Super, vielen Dank Dir schonmal soweit. Hab das mal versucht und bekomme die Fehlermeldung:


    Ungültige Statische Route und die 10er adresse in rotem Rahmen. (Es ist 10.8.0.1)


    An was kann das liegen?


    Muss das Ziel zu dem Zeitpunkt verfügbar sein?


    Grüße

  • Muss das Ziel zu dem Zeitpunkt verfügbar sein?

    Nein, das Gateway muss eventuell verfügbar sein, also VPN Server aktiv, aber selbst das kann ich mir bei der Erstellung von Routen nicht vorstellen...


    Bin leider auch kurz angebunden heut abend, versuche die Tage mal zu schauen wie das war und ob ich da nen Denkfehler oder was vergessen habe... hatte das auch mal so im Einsatz, war eigentlich unkompliziert...

  • Ich hatte bei mir nochmal nachgestellt, wie ich es mal temporär laufen hatte. Allerdings war es andersrum und die Route wurde auf dem VPN client eingerichtet. In diesem Fall erstellt man die Route und wählt dabei das VPN Interface. Das geht so aber nicht auf dem System mit dem VPN Server. Keine Ahnung wie man das sonst bewerkstelligen soll....

    Als Alternative könntest du dein Zielsystem / VPN Client in HBS so einrichten, dass es sich die Daten von der Quelle holt. Dann kannst du die Route einrichten und dein Quellsystem mit der LAN IP ansprechen. Weiterer Vorteil: dann kann der Job auch nicht versehentlich schief gehen, wenn das Zielsystem mal nicht vollständig hochgefahren ist etc.

  • Aber irgendwie bin ich zu dumm um das HBS zum "Saugen" einzurichten, ich kann irgendwie immer nur das Lokale NAS als Quelle auswählen und nicht das entfernte...

  • Aber irgendwie bin ich zu dumm um das HBS zum "Saugen" einzurichten

    Den Schuh muss ich mir anziehen: ich hatte nicht erwähnt, dass das nur nit einem Sync Job möglich ist. Dazu muss das entferne NAS als Speicherplatz in HBS angegeben werden und natürlich muss RTRR (oder Protokoll deiner Wahl) auf den entfernten NAS aktiviert sein. Eine Versionierung ist damit nicht möglich. Hierbei kannst du auch die IP vom VPN als Ziel angeben (10.8.0.1 bei Standardeinstellung), die VPN IP des Servers bleibt ja immer gleich...


    Für deinen Fall ist das alles was mir einfällt. Etwas OT (oder auch nicht): Openvpn zielt auf roadwarrior ab, also auf clients, die "von unterwegs" auf das Netz des VPN Servers Zugriff haben sollen. Du wolltest ursprünglich, dass das Netzwerk, in dem der VPN Server steht, Zugriff auf den Client hat. Das ist mit openvpn zwar möglich, bedarf aber etwas "speziellerer" Konfig, die QVPN nicht ermöglicht (zumindest nicht per GUI, mit Basteln könnte da was gehen).

  • Verstehe, vielen Dank schonmal. Das heißt du würdest ein anderes Protokoll bevorzugen? Zum Beispiel IPSec oder so und dann den Server auf dem Ziel-NAS laufen lassen?

    Versionierung wäre einigermaßen wichtig, deshalb will ich eigentlich keinen Sync-Job :)


    Grüße

  • Bei IPsec dürfte egal sein auf welcher Seite der Server läuft, aber mit dem Protokoll kenne ich mich nicht aus. Bei openvpn sollte der Server auf der Zielseite laufen, damit sich der Client dorthin verbinden kann. Wie es dann mit einem restore aussieht ist aber auch fraglich. Eine Verbindung von Serverseite zu Client ist wie gesagt mit openvpn etwas umständlicher und der Server muss die entsprechende Möglichkeit zur Konfiguration bieten (client specific override).


    Ich denke IPsec wäre die bessere Wahl, weiß aber auch nicht wie gut es bei QNAP implementiert ist und ob es dann so läuft wie gewünscht, denn mit der openvpn Implementierung auf qnap ist ja auch nicht alles möglich...

  • Okay, ich habe nun folgendes gemacht. Ich habe auf dem ZielnNas einen QBELT-Server am laufen, hoffe dass die Portweiterleitung funktioniert (also IPv4/DDNS) und habe einen RTRR Server laufen. Und dann schicke ich vom Quell-NAS den Auftrag und so sollte es ja funktionieren. Und für den Zugriff von mobilen Endgeräten habe ich auf dem Quell-NAS einen OpenVPN Server laufen ...


    Bin mal gespannt.