Beiträge von tiermutter

    Moin,


    das ist alles schon etwas verwirrend, aber ich glaube so langsam ein wenig verstanden zu haben...


    Wie schon zuvor erwähnt bereitet es Probleme wenn Du an Ethernet und WLAN Adapter die gleiche IP verwendest (an welchen Adapter soll Dein Rechner denn die Anfragen schicken? Er wird wohl den Adapter mit dem Gateway/ Router nehmen, da gibt es diese Adressen (QNAP) aber nicht!

    Wenn Du beide Netzwerke verbinden willst (ich vermute ein Patchkabel von Router zum Switch ist nicht möglich) brauchst Du eine WLAN Bridge.

    Ein Windows Rechner kann das z.B. übernehmen (solange er an ist), ob ein Mac das auch kann weiß ich nicht, damit hättest Du dann eine schnelle Lösung um die beiden Netzwerke (über Deinen Rechner) zu verbinden.


    Edit:

    Erreichst Du die QNAP denn wenn Du das WLAN trennst?

    Moin,


    das Antivirus prüft nur die Daten die auf Deinem System abgelegt sind, aber nicht das System selbst. Dazu solltest Du Dir in erster Instanz "Malware Remover" aus dem AppCenter installieren, eine andere Idee womit man das weitergehend prüfen kann kenne ich nicht.

    Schau doch mal im Ressourcenmonitor nach welche Prozesse die CPU derart belasten.


    Wenn das NAS Probleme im LAN bereitet könnte es auch daran liegen, dass Adapter/ virt. Switch falsch konfiguriert ist, aber dazu steht glaube ich allerhand in dem anderen Thread den Du angeführt hast.

    ?(

    Ein bisschen spärlich diese Aussage...

    Natürlich ist ein VPN Zugriff grundsätzlich auch bei DS Lite (wie wir ihn bei der DG haben) möglich, nur halt eben ausschließlich über IPv6.

    Könnte demnach so gemeint sein, dass es mit dem QNAP einfach nicht geht :/

    Hab es auch noch nie gehört dass es jemand am Laufen hat, ich lese immer nur Theorie wie es klappen könnte.

    Du könntest hier noch mal nachhaken ob der TE etwas erreicht hat:

    VPN mit OpenVpn und Port-Mapping (feste-ip.net), brauche Hilfe

    EDIT: sehe gerade dass Du da schonmal nachgefragt hast ;)


    Ansonsten könnte PCP ein Lichtblick sein, Deine Fritte kann das, ist die Frage wann DG das kann oder überhaupt macht:

    https://www.dasheimnetzwerk.de…otokolle/Eintrag_PCP.html

    Also ich weiß nicht ob die Fritte beides gleichzeitig kann, aber du hast bei der Fritte DHCP6 und beim qnap SLAAC (stateless) eingestellt. Stell den qnap mal entsprechend auf stateful (dhcp6) um.

    Wenn du dann beim qnap statt auf Adapter konfigurieren auf Info oder Status klickst, werden dir die zugewiesenen Adressen angezeigt. Die Adresse die in deinem Screenshot ausgegraut ist scheint korrekt zu sein, aber ich weiß nicht ob die aktuell auch wirklich zugewiesen ist...

    Hm, das mit der "festen IP" verwirrt mich etwas... Aber der qnap dürfte keinesfalls die gleiche IP wie die Fritte kriegen. Evtl ist damit die WAN ipv6 gemeint?

    Der qnap selbst muss eine Adresse haben die in den ersten (vermutlich) vier Blöcken identisch mit dem in der Fritte angegeben ipv6 Präfix ist.

    Wie verteilt die Fritte denn die ipv6? Standard ist glaube ich DHCP6 eingerichtet...

    Schick doch besser mal Screenshots und blende Teile der ipv6 Adressen aus.

    Wenn der qnap nur auf ipv6 rennt ist natürlich mit ipv4 nichts mehr anzufangen 8o

    Sogesehen ist die config mit tcp6 korrekt, fraglich ist nur ob der server wirklich entsprechend gestartet wird.

    Hat der qnap denn definitiv eine globale ipv6? Müsste bei dg mit 2a00:6020 beginnen... Solltest du nur eine link local (fe80:) haben, dann kann der server darauf ohnehin nicht erstellt werden.


    Gibt es beim qvpn denn irgendwo logs die das startverhalten des vpn Servers abbilden? Da müsste man ja noch etwas sehen können :/

    Wenn du lokal schon keine Verbindung aufbauen kannst dann ist die Fritte doch eh erstmal außen vor...

    Beim Client ist egal ob da tcp oder tcp6 steht, wenn er eine ipv6 zum verbinden bekommt nimmt er bei tcp auch ipv6, den kannste also auf tcp stehen lassen.

    Aber lass mich raten: wenn du die interne ipv4 nimmst baut er eine Verbindung auf?

    Würde dann bedeuten dass der Server weiterhin auf ipv6 erstellt wird...

    Tatsächlich sind die Lizenzen unbegrenzt gültig, also einmal kaufen und endlos nutzen, wenn ich das richtig verstanden habe.

    Habe mich damit allerdings noch nicht wirklich viel auseinandergesetzt...


    Im Tmobile Netz hast Du bereits IPv6, also was das angeht kannst Du Dir den Portmapper sparen!

    Wenn Du lokal allerdings zur IPv4 verbunden hast, dann bedeutet das, dass der QNAP den Dienst auch auf IPv4 gestartet hat und nicht auf IPv6!

    Ich bin auch immer noch nicht davon überzeugt, dass der QNAP den Socket auf IPv6 überhaupt erstellen kann... es gibt da zwar Walkarounds zu, aber dass das wirklich funktioniert habe ich noch nie bestätigt bekommen, so lange glaube ich auch, dass der QNAP das gar nicht kann, denn wenn er es könnte, dann gäbe es auch die entsprechende Option, so meine Theorie... das wäre eventuell mal eine Frage an den Support wert, denn das Thema beschäftigt einige glaube ich...


    Das wäre meiner Meinung nach also das erste was zu prüfen wäre: lokal zur globalen IPv6 des QNAP verbinden und schauen ob eine Verbindung aufgebaut wird, Voraussetzung dazu ist natürlich dass der QNAP sowie der Client eine IPv6 bezogen haben.

    Ja, die kleine Platine übernimmt die Verschlüsselung zum Server, die brauchst Du dann in jedem Fall, dafür kannst Du mit 50€ Materialpreis rechnen, für die Lizenz bist Du bestimmt mit 30-50€ je Endgerät dabei, je nachdem wie gut Dein Errichter für Dich kalkuliert 8o


    myqnapcloud brauchst Du bei der aktuellen Konstellation nicht. Wenn möglich würde ich den vServer erstmal aus der Config rausnehmen, den brauchst Du ja nur wenn Dein Client keine IPv6 Konnektivität hat, z.B. Vodafone Mobilfunk...

    Wenn es lokal zumindest zwischendurch schonmal geklappt hat, dann ist ja wenigstens schonmal klar, dass der QNAP das VPN auf IPv6 aufbauen kann.

    Wie hast Du Dich denn lokal mit dem VPN verbunden? Direkt die globale IPv6 des QNAP zum Verbinden angegeben?

    tcp6 beim client ist nicht zwingend nötig, der sucht sich schon das Passende raus, tcp6 müsste sogar eher falsch sein, da Du die Verbindung zum Portmapper ja über IPv4 aufbauen musst, so aber IPv6 erzwingst... hier würde ich auf tcp stehen lassen.


    Kannst Du in den Logs vom QNAP VPN denn irgendwelche Aktivitäten sehen wenn Du von außen eine Verbindung aufbauen willst?

    Moin,


    welche Aufgabe hat denn der vServer dazwischen?

    Sofern das QVPN überhaupt einen Server auf IPv6 erstellen kann solltest Du eigentlich direkt auf den QVPN Dienst zugreifen können, auch wenn es nicht sinnvoll ist den QNAP nackt ins Netz zu stellen. Der QNAP muss sich nur entsprechend eine IPv6 von der FB beziehen... ist dem QNAP aktuell denn eine globale IPv6 zugewiesen?


    Und was spricht gegen deine "alte" Lösung mit dem VPN zur Fritzbox? Kann die das auf IPv6 nicht mehr?


    Telenot stellt seit kurzem übrigens den "hiXserver" zur Verfügung, diesen Dienst kannst Du für ein einige Taler erwerben, damit baut die EMZ eine Verbindung zum Server auf sodass alles darüber läuft. Damit braucht man sich wegen IPv6 und Freigaben oder VPN keine Gedanken mehr zu machen. Hilft aber halt auch nur für dieses eine Gerät ;)

    Moin,


    ich selbst habe mich mit der Thematik nicht weiter befasst, weil ich es nur temporär als fallback einrichten wollte, hab es dann aber sein gelassen...


    Den (QVPN) Serverdienst allein neu zu starten hilft nicht viel, da Du die Datei geändert hast, die beim Booten des gesamten Systems geladen wird.

    Du musst also entweder den QNAP neu starten oder um das zu umgehen die server.conf zusätzlich anpassen.

    Ob es dann allerdings funktioniert ist eine andere Sache :S

    Auch wenn ich oben selbst irgendwo TCP als Protokoll angegeben habe: Für OVPN verwendest Du besser UDP statt TCP wenn Du die Wahl hast...

    Moin,


    um auf die Datei zugreifen zu können benötigst Du einen SSH client, z.B. Putty.


    Damit meldest Du Dich mit Username und Passwort an, zuvor musst Du am Qnap SSH aktivieren (und nach getaner Arbeit besser wieder deaktivieren).

    Nach erfolgter Anmeldung gibst Du folgendes ein:


    cd .. [Leerzeichen beachten]

    vi /etc/init.d/vpn_openvpn.sh


    Damit hast Du die Datei im vi-Editor geöffnet. Zum Bearbeiten drückst Du die Taste EINFG, nimmst Deine Änderungen vor, beendest den Editiermodus mit ESC, speicherst die Datei mit der Eingabe :w! und beendest den Editor mit :q.


    Mir passiert es dummerweise ziemlich schnell, dass ich versehentlich etwas editiere, was ich nicht wollte, achte also besser bei jedem Tastendruck darauf was Du anstellst. Notfalls beendest Du den Editor statt mit :w! mit :q! ohne zu speichern.


    Ich bin mir allerdings nicht sicher ob der Qnap einen OVPN Server überhaupt auf ipv6 erstellen kann, mein Asus Router konnte es seinerzeit nicht, zumal der Server mit der Standardconfig "proto tcp" bereits auf v4 und v6 erstellt werden müsste.


    Bedenke aber dass es nicht empfehlenswert ist einen Qnap nackt ins Netz zu stellen...

    hm, also bei mir sieht es momentan so aus:


    TS-219P @4.3.3: nach mehrfachem Versuch nicht behoben

    TS-453A @4.4.1: nach mehrfachem Versuch nicht behoben

    TS-453A @4.3.6: war gar nicht erst betroffen

    TS-431+ @4.3.6: war gar nicht erst betroffen

    TS-459 Pro II @4.2.6: ist betroffen, habe den Fix aber noch nicht ausprobiert


    Aber gut zu wissen dass wir uns keine ernsthaften Sorgen machen müssen, meine 459 Pro II habe ich gestern Abend als es losging aus Angst heruntergefahren :S

    Die zugehörigen Datenbanken wurden bereits geupdated allerdings müssen Sie, damit der Fix auf Ihr System angewandt wird die App Malware Remover neu installieren.

    Funktioniert bei meiner TS-453A (4.4.1 beta) nicht, Meldungen kommen wieder.

    bei meiner 219P habe ich den MR vor 15min bereits neu installiert, brachte auch keine Besserung.

    Moin,


    danke für Deine Antwort!

    Ich habe gestern nochmal getestet, diesmal auch die 459Pro II... nachdem ich die USV Einstellungen hin und her geändert habe, also quasi die USV neu verbunden habe, reagiert das Gerät nun wieder ordnungsgemäß, hoffentlich bleibt das auch so, ich möchte das Verhalten nicht jeden Monat aufs Neue testen wollen :S

    Gleiches bei der 219P brachte aber keinen Erfolg...

    Ggf. ist dir mit der Zeit ja die QTS Konfiguration durcheinander geraten.

    Kannst ja, wenn Backup vorhanden mal die 219 neu einrichten.

    Das Gefühl habe ich auch so langsam... auffällig beim gestrigen Test war auch wieder, dass das Gerät trotz erkannter Wiederherstellung der SV nach etwa 3 Stunden heruntergefahren wurde. Beim Test am Vortag passierte das nach 20min.

    Auch hatte ich beim Test am Vortag so meine Problemchen mit der 219P... beim Wiedereinschalten bekam ich merhfach die Meldung, dass die Aktualisierung des OS fehlgeschlagen sei (das Update war aber schon seit einer Woche durch), beim Reboot Versuch reagierte das Gerät gar nicht mehr, etc.. Das hatte ich aber auf das harte Abschalten beim Stromausfall geschoben.

    Wie dem auch sei, das Problem muss seinen Ursprung schon vor dem Stromausfall haben, um eine Neueinrichtung komme ich wohl nicht herum.

    Auch ein Update der AP9630 ist nicht verkehrt wenn man auf die UPS App Version aufpasst.

    Da gibts leider 3-4 verschiedenen Versionen für alle möglichen APCs.

    Die rennt noch auf 6.6, das Update liegt aber schoon bereit, eventuell kann ich mich der Sache heute Abend annehmen...


    Ein bissl Bauchweh bereitet mir das Ganze aber schon... so ein Verhalten an zwei Geräten mit unterschiedlichen FW Ständen...

    wie soll man sich nachher darauf verlassen können, dass es beim nächsten Mal korrekt funktioniert???

    Ich habe dazu mal ein Ticket eröffnet, mal sehen was bei rumkommt...


    Gruß

    Moin zusammen,


    bei uns gab es gestern eine angekündigte Stromabschaltung für etwa 4 Stunden.

    Die drei betroffenen QNAP hängen alle an einer USV per SNMP, leider war das Verhalten der QNAP diesmal alles andere als das, was ich erwartet bzw. eingestellt habe.

    Folgende Hardware und Einstellungen sind betroffen:


    TS-459 Pro II, QTS 4.2.6, auto protection mode nach 30min

    TS-219P, QTS 4.3.3, shutdown nach 10min

    (TS-453A, QTS 4.4.1, auto protection mode nach 10min)

    alle per SNMP an einer APC Smart UPS X 1000 mit AP9630


    Das Verhalten der 453A war wie erwartet: auto protection mode nach 10min, Systemstart bei Wiederherstellung der Stromversorgung.

    Die 459 Pro II erkannte die Unterbrechung tadellos und gab die Meldung aus, dass in 30min der auto protection mode eingeleitet wird. Das System wurde nach 30min allerdings komplett heruntergefahren und entsprechend nicht wieder eingeschaltet, als die SV wiederhergestellt war.

    Die 219P erkannte die Unterbrechung ebenfalls tadellos und gab die Meldung aus, dass in 10min abgeschaltet wird. Hier passierte allerdings gar nichts, in den Ereignissen ist auch nicht zu erkennen, dass überhaupt ein Dienst gestoppt und das Herunterfahren eingeleitet wurde. Entsprechend wurde das System etwa 50min nach dem Ausfall hart abgeschaltet, als die USV alle Lasten abgeworfen hat. Der Shutdown dauert bei dem Gerät normalerweise auch nicht annähernd länger als 10min, da hier außer nem RTRR Server auch keine sonderlichen Dienste laufen; das Gerät hätte also schon lange abgeschaltet sein müssen.


    Die Einstellungen der QNAP waren alle i.O. und die Geräte kündigten ja auch das eingestellte Verhalten an.

    Seit dem letzten Test der Konfiguration vor etwa 1,5 Jahren hat sich nichts geändert, außer gelegentlich die FW, da hatte alles einwandfrei funktioniert.

    In den Einstellungen der USV (ebenfalls unverändert seit letztem Test) ist mir lediglich aufgefallen, dass die 453A (bei der war ja alles gut) noch nicht als SNMP Trap Receiver konfiguriert war.
    Diesen hatte ich bei anschließenden Tests hinzugefügt, das System reagierte weiterhin korrekt.


    Beim anschließenden Test an der 219P hat sich herausgestellt, dass das System (nach 1min) erneut keinen Shutdown eingeitet hat, obwohl angekündigt.

    Als die SV wiederhergestellt war erkannte das Gerät dies korrekt, wurde aber aus mir unbekannten Gründen 20min nach Wiederherstellung der SV abgeschaltet.


    Ich weiß leider nicht wie ich hier weiter verfahren kann, ein Reboot hat zumindest bei der 219P nichts gebracht, auch die USV neu zu verbinden hat nicht geholfen.

    Da in diesem Fall ja auch zwei Geräte mit unterschiedlichen QTS betroffen sind gehe ich davon aus, dass es nicht an einer fehlerhaften Soft- oder Hardware liegt.


    Hat jemand eine Idee?

    Gruß

    Marc