Rsync remote über VPN mit HBS3

  • Hi zusammen,


    ich hab die Foren durchsucht, bin aber nicht so richtig weiter gekommen. Vielleicht hat jemand so etwas schon erfolgreich umgesetzt.

    Folgendes ist geplant: Zwei NAS, räumlich getrennt, können mittels WireGuard VPN miteinander sicher kommunizieren. NAS A soll regelmäßig und automatisch mittels RSYNC ein (inkrementelles) Sichern bestimmter Ordner auf NAS B vornehmen.

    Mein Plan war nun, das mittels HBS3 One-Way Sync zu realisieren, also NAS A die Daten auf NAS B schicken zu lassen, die sich verändert haben seit dem letzten Mal. Klappt aber nicht. Das rsync-Ziel findet NAS A nicht, und meldet access denied, obschon die WireGuard VPN-Verbindung erfolgreich steht und der User beim remote NAS B auch vorhanden ist und rsync darf. Was muss ich tun? Und muss ich die WireGuard-Verbindung konstant an haben, kann ich die nicht zusammen mit dem sync-job scheudlen?

  • Ich habe so etwas eingerichtet mit HBS3, jedoch nicht rsync sondern die RTRR variante genommen. Wenn es nicht gerade daran liegt, dass rsync nicht funktioniert, dann spricht nichts dagegen das so einzurichten.

    It der Rsync Server denn eingeschaltet auf dem Ziel-NAS? Hast Du überprüft ob die IP Adresse stimmt? Bei einer VPN verbindung kann man sich nicht auf die Namensauflösung verlassen, Nimm die IP Adresse.

    Teste ob der rsync server erreichbar ist:

    Logge Dich auf dem Quell Nas mit einer SSH oder Terminalsitzung ein.

    und dann mal:

    telnet ip.addr.des.Zielnas 873

    was passiert?


    Was die Frage nach der WG verbindung angeht: Ich habe nichts gefunden, dass es ermöglich die verbindung nach bedarf aufzubauen. Entweder an oder aus. Es schadet aber ja nicht wenn die Verbindung an ist. Daten fliessen darüber nur wenn notwendig, ansonsten nur sehr wenig. Deine Internet sollte dadurch nicht belastet werden.

  • Screenshots wären hilfreich.

    Wer steuert den Job? Der VPN Server oder der Client?

    Welche IP wird als Ziel angegeben? Die wireguard IP oder die LAN IP?

    Funktioniert die WG Verbindung überhaupt? Funktioniert ein ping?

  • Wo terminieren die VPN Verbindungen, klingt irgendwie als wenn beide auf dem jeweiligen NAS direkt aufliegen.


    Besser ist es hier den Router für so einen Tunnel zu verwenden.

  • vielen Dank für eure Antworten bzw Rückfragen.

    also: die VPN-Verbindung endet auf dem Router, sie wird vom NAS A aufgebaut. Mit IP-Adressen habe ich es bereits versucht. RSYNC läuft von anderen clients aus, auch via shell, nur eben nicht per hbs3. Nur wenn NAS B den sync-job steuert und die vpn-IP von NAS A anspricht, läuft es.

    Umgekehrt aber nicht.

  • Hört sich an wie ein routing firewall oder NAT problem.

    Schildere doch mal die jeweiligen Netzwerkeinstellungen.

    Subnetz A, Subnetz B, eventl. Subnetz für VPN. Router: hersteller etc. etc.

  • Hallo,


    welche HBS3-Version wird denn genutzt ? :/


    Die aktuelle Version 24.0.0304 scheint einige Probleme zu haben. :(


    Fehlercode HBS 3 V24.0.0304 - Backup & Sicherungsmanager - NAS Hilfe und Support Forum (qnapclub.de)

    Bei einigen hat die Installation der Vorgängerversion geholfen.


  • Ich kann einen Fehler der aktuellen Version berichten vom QVPN (Auf Quts):

    Wenn man eine Verbindung macht mit Wireguard und nimmt den WG client auf dem Quell-NAS.

    und wenn man mit WG Server im Netz des Ziel-NAS, den Client in ein anderes Subnetz setzt.

    Also, z.b.: Subnetz NAS mit HBS3 Server der empfängt: 192.168.10.0, aber WG IP Adresse client NAS: 192.168.20.0

    Dann braucht man eine route vom 192.168.20.0 netz in das Netz 192.168.10.0.

    Die muss man in WG config eintragen, ggf. manuell.

    Funktioniert auch eine Zeitlang, aber nach ca. 2Tagen vergiss das WG auf dem Quell-NAS die route. Also keine verbindung mehr vom Quell zum ZielNAS. Somit kein Sync mehr.

    Auch eine Trennung und erneutes Verbinden hilft nichts.

    Ich habe dann als umweg eine statische Route vergeben. Seit 3 Tagen funktioniert es.


    Das kann aber icht das problem hier sein, denn hier geht es ja in einer Richtung. Wäre die route nicht da würde es überhaupt nicht gehen.

  • also. TP-Link Router ER605. WireGuard subnet 192.168.44.1/24


    NAS B: QNAP TS-453-Be mit QTS 5.1.6.2772

    192.168.99.22/24

    HBS 3 Version 24.0.0304


    NAS A: QNAP TVS-671 mit QTS 5.1.5.2679

    192.168.1.200/24 WireGuard 192.168.44.99/32

    HBS 3 Version 24.0.0304

  • Also:

    Also qnap TVS-671 mit wireguard client- ->(router)----internet----(wireguard 192.168.44.0/24)(ER605)-(192.168.99.0/24)->TS453-BE


    Vielleicht gibt es ja ein ahnliches problem wie von mir mit der Route die vergessen wird auch bei Dir? Hast Du mal nachgekuckt? Ineine shell auf dem NAS B: netstat -rn. Existiert die router in das 192.168.99.0 subnetz?


    Die beiden Netzwerke auf dem ER605, die sind mit routing verbunden und nicht mit NAT? Und es gibt auch keine Filter oder sicherheitssoftware die noch die Finger mit drin hat? Ist auf dem NAS A auch jeder Firewall deaktiviert?

  • NAS B kann die Route ja nicht haben, er ist ja nicht teil des VPN. NAS A hat sie. Aber NAS B kann 192.168.44.99 erreichen, denn der ER605 löst die IP-Adresse sauber auf und routet.

    Ich fürchte, es ist die Firewall des ERP605. Ich probiere daran nochmal weiter, ansonsten verwaltet eben NAS B den Backup-Job.

  • Richtig. ich bin durcheinandergekommen mit A und B.

    Firewall oder NAT, viele andere Varianten gibt es nicht.

    Den Router kenne ich leider nicht.

    Kommt das NAS A mit einem Ping noch auf die 192.168.99.1 (ip des routers?)

    oder nur bis zur IP des Routers im WG Netzwerk?

  • keines davon, weder die lokale IP des routers noch dessen WG-IP noch die LAN-IP des NAS B. Die Verbindung steht, ich komme per ssh auf NAS A und HBS3 geht von NAS B aus, aber NAS A sieht nichts vom remote Netzwerk. Die Route steht aber:



    ok, da war ein Fehler in der config des routers. der WG server war auf ner anderen IP. Nun kann ich den auch sauber pingen von NAS A aus.

    Aber nicht NAS B.

    und es liegt nicht am router oder der Firewall. andere WG clients können problemlos das subnetz von NAS B erreichen, wenn sie sich via VPN eingewählt haben. Nur der NAS A schafft das nicht. Bleibt aber selbst vollkommen ok erreichbar unter seiner VPN-IP.

    andere IPs im WG-Subnetz 192.168.44.0/24 erreicht er ebenfalls. Trotz /32 in der WG-config (etwas anderes geht ja auch nicht bei QVPN und ist auch so beim router konfiguriert). Nur eben sieht NAS ! nichts im Subnetz 192.168.99.0/24, obwohl andere clients genau das können und NAS A eben aus demselben perfekt erreichbar ist. Routing klappt also auch.


    Der QVPN Service ist auf NAS A übrigens in der Version 3.2.1051 Build 20240414 unterwegs.

    5 Mal editiert, zuletzt von void () aus folgendem Grund: Ein Beitrag von void mit diesem Beitrag zusammengefügt.

  • ich habe heute weiter herumprobiert. Selbst eine OpenVPN-Verbindung half nicht.

    Dann habe ich bei der WireGuard VPN auf NAS A die Allowed IPs auf 0.0.0.0/1, 128.0.0.0/1 gesetzt. So habe ich das in manch anderen clients, wenn ich nicht allen traffic über WG schicken will. Nun ist NAS A offline. offensichtlich nutzt er das loopback für den Qvpn Server-Part. na sauber.

  • So habe ich das in manch anderen clients, wenn ich nicht allen traffic über WG schicken will.

    Genau das wird damit aber erreicht... Es ist nur eine andere Schreibweise von 0.0.0.0/0

  • ah, darum. Nun, ich hab es nun unabhängig davon endlich geschafft.


    Unter Advanced Settings in QVPN auf NAS A habe ich als Allowed IPS eingegeben:

    0.0.0.0/1, 192.168.99.0/24

    Nach erneutem Aufbau der Verbindung sehe ich nun nicht mehr nur aus dem Subnetz von NAS B das NAS A unter dessen VPN-IP, sondern ich kann auch von NAS A aus das Subnetz von NAS B sehen.
    Ich hatte die Einstellung von WireGuard bislang immer falsch verstanden. Ich dachte, diese bezöge sich auf die erlaubten IP-Adressen, die der Client haben darf, aus denen er die Verbindung zum VPN Gateway aufbauen darf. Dass das routen konstatiert, deren traffic durch den VPN darf, war mir nicht klar. Nun ist alles klar :)

    übrigens läuft das sync via rsync sowie smb/cifs und auch backup via RTRR und webdav tadellos. Ich teste nun, welche Verbindung die schnellste und zuverlässigste ist für meine Zwecke.