Beiträge von void

    Ich habe ein Backup der ganzen Maschine angestrebt. via webdav auf einen entfernten, privaten cloudspeicher.

    5,75 TB. Aber nach sechs Stunden und 10 Sekunden exakt ist der Job in HBS3 Version 24.0.0304 abgebrochen mit Fehler - das Ziel sei nicht erreichbar. Kennt das Verhalten jemand?

    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.

    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.

    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.

    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.

    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

    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.

    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 in HBS3 mehrere backup jobs, die von einem älteren NAS im Keller die Daten spiegeln. Dieser NAS ist mit dem Hostnamen als Verbindung eingespeichert. Das ging bisher immer einwandfrei.

    Aber neuerdings bekomme ich im QnapOS generisch die Fehlermeldung, dass mein DNS Server die Hosts nicht auflösen könnte:

    pasted-from-clipboard.png

    Ohne mehr Informationen, welche Applikation und was genau. Nachdem die backup jobs fehlschlugen, kam ich darauf, dass er den Namen des zweiten NAS nicht aufgelöst bekam. Die DNS-Einstellungen bekommt er vom DHCP meines routers: 192.168.1.1 und 1.1.1.1. Ersterer kann NAS.DOMAIN und NAS auflösen, weil er per split dns diese Einträge erkennt.

    Kennt jemand dieses Problem auch? Ist das generisch auf dem QNAP und ich muss etwas an der netzwerkkonfiguration ändern, etwa den secondary dns raus nehmen?


    wenn ich per ssh nach dem NAS suche:

    bekomme ich wie ihr seht nur saubere antworten, wenn ich einen DNS-Server angebe. Auch den von cloudflare, interessanterweise. Mein split-dns am router funktioniert also. Nur will QNAP das nicht mehr?

    Hi zusammen,


    ich habe wie hier beschrieben das DVD+-RW in eine debian lxc weitergereicht auf meinem qnap.

    soweit geht auch alles, allerdings ist udev seltsam.

    und für /dev/cdrom dasselbe. Dies ist ein manuell angelegter symlink auf /dev/sr0 weil programme wie eject dann keine parameter brauchen.

    Ich wollte nunmehr ein script starten, wenn eine Scheibe eingelegt wird ins Laufwerk. also habe ich in /etc/udev/rules.d/99-auto-instert.rules

    Code
    ACTION=="change", SUBSYSTEMS=="block", KERNEL=="sr[0-9]*", RUN+="/usr/bin/detectCD.sh"

    jedoch löst dieses script anscheinend nie aus, obschon das event vorkommt:

    Code
    udevadm monitor
    monitor will print the received events for:
    UDEV - the event which udev sends out after rule processing
    KERNEL - the kernel uevent
    
    
    KERNEL[32162.657079] change   /block/sr0 (block)

    im Testmodus geht es aber wohl:



    was habe ich bloß übersehen?

    hallo zusammen,


    ich hab in einem Debian LXC den Zugriff auf die Audiofunktion erfolgreich eingerichtet. Allerdings kann ich nicht wählen, ob er den Speaker oder den Stereoklinkenanschluss auf der Rückseite bedienen soll. Stehe ich auf dem Schlauch oder lässt alsa das nicht zu:

    nun, so ganz sicher bin ich da nicht. ich fürchte, ich war zu ungeduldig. irgendwann hat die container station wohl die json wieder gefunden von dem container. gestartet ist er allerdings nicht mehr, ich hab das image zu sehr verbastelt. also habe ich sie gelöscht und neu angelegt.