Beiträge von void

    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.

    Hallo zusammen,


    ich habe die Datei /usr/share/lxc/config/debian.common.conf angepasst, da ich Zugriff auf ein externes DVD-Laufwerkhaben wollte. Das hat soweit auch ganz gut geklappt (bis auf das einbinden des devices). Nur ist nun der Container für die Container Station verschwunden? Reboot des containers half nicht. Reboot des NAS half nicht. Der Container startet auch nicht, wie es scheint, obschon er auf autostart eingestellt war.

    Was nun?


    --edit

    hat sich erledigt.

    Danke für's vormachen :) ich hab nun in meinem container das DVD-Laufwerk ebenfalls funktionierend, allerdings verschwindet das Gerät nach jedem Neustart aus /dev/

    warum?


    --edit


    ich hab den Fehler gefunden! und das Problem mit den Änderungen in der common.conf auch!

    du darfst nicht im Image-Ordner bearbeiten, sondern musst dich mit

    /share/Container/container-station-data/lib/lxc/[container-name]/config befassen!

    dann klappt es auch mit der Nachbarin ;) sound und dvd-Laufwerk durchgereicht, sauber.


    Klar, das config-file im Image-Ordner (/share/Container/container-station-data/image/lxc/debian-buster/image) gilt ja nur als Template für neu erstellte Container.

    ich hab das mit den macs gelöst. die bleiben, wenn ich eine manuell eingebe beim erstellen des containers. sonst nicht.

    aber noch was: wenn ich zwei verschiedene hosts habe auf dem selben port, dann brauch ich doch nen proxy, oder verstehe ich das falsch?