kein Zugriff via Central Management System bei Direktverbindung

[Huibuu]

Gesundes neues Jahr!

Ich schlage mich mittlerweile seit Tagen mit dem Thema rum und komme der Lösung keinen Schritt weiter...

Mein Netz soll so aussehen um das Backup getrennt von der Prouktivumgebung zu haben:
Mac <> Router <> DS220+ < Direktverbindung > DS118 (Backup)
xxx.105 <> xxx.1. <> xxx.230 (Lan1) yyy.106 (Lan2) < LAN_Kabel > yyy.103

Das administrieren der DS118 soll über das Central Management System erfolgen.

Nachdem ich unter anderem bereits folgende Stickwörter (Direktverbindung, Direktanbindung, Lan to Lan, NAS NAS, Central Management System) hier im Forum gesucht sowie gegoogelt habe, muss ich nochmal ein neues Thema aufmachen...

Zu Anfang habe ich über das CMS die DS118 neu bespielt. Das ging so "semigut", nachdem ich DSM separat gedownloadet habe.
Schlussendlich hat das CMS aber nach der Installation keine Verbindung zur DS118 aufgebaut, obwohl er diese mit der DSM bespielt hatte.

Mittlerweile habe ich die DS118 und 220 sowohl mit verschiedenen IP´s probiert und/oder verschiedenen Subnetzen. Egal wie ich es drehe und wende (im Rahmen meines Verständnisses) ich bekomme mit CMS keine Verbindung, obwohl die 220 die 118 "sieht".

Wo genau könnte mein Fehler liegen? Wie sehe ich die richtige Konfiguration aus?
Das einzige was ich bisher unter den Stichwörtern gefunden habe ist, dass die IP der 220 und 118 aus demselben Bereich kommen sollen.
Also beispielsweise xxx.yyy.zzz.103 und xxx.yyy.zzz.106

Wenn ich die 118 an den Router hänge funktioniert CMS problemlos...
Meine Vermutung ist, dass das Routing falsch läuft. Z.B. das CSM standardmäßig stets den Router (LAN1) fragt, ob er die IP der 18 kennt, der sieht die nicht und verwirft die Anfrage. Oder die Signale der 220 kommen an der DS118 an, die Antwort wird aber falsch zurückgesendet oder nicht richtig empfangen.

Die Konfiguration lass sich in der Vorbereitung so einfach...

 

[blurrrr]

Bei einer Direktverbindung zwischen 2 NAS braucht es ein "anderes" Netz. Zum Beispiel:

LAN: xxx.yyy.zzz.220 (1. NIC)
Extra: xxx.yyy.XXX.220 (2. NIC) + xxx.yyy.XXX.218 (1. NIC)

Damit ist die 218 erstmal "nicht" aus dem normalen LAN erreichbar, da die Clients die Route entsprechend nicht kennen. Die 220 hingegen sollte dann aber schon mit der 218er kommunizieren können (wichtig ist auch, dass auf das 2. Interface der 220er zur 218er hin, kein Gateway gesetzt wird, nur IP+Netzmaske).

Somit sollte es (theoretisch) auch für das CMS-Paket auf der 220er möglich sein, die 218er zu erreichen. Wenn die Clients auch noch an die 218er sollten, dann muss das Forwarding aktiviert werden ("echo 1 >/proc/sys/net/ipv4/ip_forward") und die Clients müssten die Route zum 218er bzw. zum extra Netz über die 220er mitgeteilt bekommen. Von so einer Bastelei würde ich aber a) abraten und b) macht das relativ wenig Sinn, weil man dann die 218er auch direkt mit ins LAN stellen könnte. ??

 

[Huibuu]

Und genau das geht halt nicht. Ich habe nochmal beidseitig neu konfiguriert:

DS 220:


DS118:





Hierbei kommt es zu diversen Problemen:
1. Die DS118 wird ins CMS hinzugefügt, aber beim verbinden mit dieser erscheint folgende Fehlermeldung:

2. Die CMS Verbindung zu einem entfernten Server bricht ab!

3. Die Sync Drive Verbindung zum entfernten Server bricht ab!

(nach entfernen des 2. LAN-Kabels funktioniert die Verbindung zum entfernten Server wieder augenblicklich.





Muss ich an anderer Stelle noch etwas konfigurieren?

Beispielsweise hier?






In einem anderen Thema hatte ich zudem mal gelesen, dass die IP´s nicht aus einem anderen Netzwerk stammen müssen!?

 

[blurrrr]

Das hat vermutlich was mit Metriken zu tun, aber ich würde Dir mal nahe legen, dass Du die Netzwerkmaske von der 2. NIC (LAN 2) mal korrigierst (255.255.0.0 ist da nämlich weniger sinnvoll - es sollte ebenfalls 255.255.255.0 sein). Irgendwelche komischen Haken brauchst Du übrigens auch nirgendwo zu setzen. Natürlich ist das 2. NAS (welches sich dann im extra Netz hinter dem anderen NAS versteckt) nicht mehr für die Clients im normalen LAN erreichbar (nur die erste DS weiss von dem extra Netz und von dem zusätzlichen NAS).

 

[Huibuu]

Gesagt, getan. Aber egal wie ich es drehe und wende, sobald die "Bestätigung" da ist und ich mich mit der DS118 über CMS "verbinden möchte"



Dieselbe Meldung kommt so gut wie immer!
Diesmal bleibt jedoch die Verbindung zum entfernten Server bestehen, ist auch schon einmal etwas
Die Clients (PC´s) sollen auch gar nicht auf den Server...
Irgendwo läuft irgendwo etwas falsch...

 

[Kurt-oe1kyw]

Kann es damit zu tun haben dass die DS118 nicht mehr auf der Liste der unterstützten Geräte für CMS drauf ist?


die wurde entfernt, obwohl sie bei mir nach wie vor einwandfrei im CMS läuft, allerdings über einen switch verbunden und im selben Netzwerk.
Kannst du mal nachsehen auf deiner DS118:
DSM > Hauptmenü > Systemsteuerung > ganz hinunterscrollen ans Ende der Liste unterhalb von Terminal&SNMP kannst du dort den Eintrag "CMS" sehen?
Falls ja, anklicken > neues Fenster > ist da unter CMS-Host die IP Adresse der DS 220+ zu sehen und daneben muss in Klammer stehen (Verbunden):


Ist da auf deiner DS118 zu sehen?

 

[Huibuu]

Nein, das kann ich nicht. Zumindest weiß ich nicht wie.
Wenn ich die DS im IP Bereich außerhalb des Routers habe, bekomme ich ja keine Verbindung mehr zur DS, außer ich setze die Netzwerkeinstellungen zurück.

Aber:
Wenn die 118 am Router hängt, dann geht die Verbindung und in der Systemsteuerung ist das CMS auch zu sehen.

ich hätte die von dir zitierte Aufstellung auch so verstanden, dass die dort genannten DS nur noch administrieren dürfen/sollen, jedoch auch nicht genannte DS administriert werden können.

das CMS zeigt mir ja grundsätzlich auch alle Daten der 118 an (Pakete, Zustand Festplatte etc), aber wenn ich auf verbinden klicke, öffnet sich ein neuer Tab, der mit dem bereits gelisteten Hinweis nach kurzer Zeit geschlossen wird. Ich komme also nicht auf die DSM Oberfläche.

 

[Kurt-oe1kyw]

ich hätte die von dir zitierte Aufstellung auch so verstanden, dass die dort genannten DS nur noch administrieren dürfen/sollen, jedoch auch nicht genannte DS administriert werden können.

oh, da muss ich jetzt ehrlich gesagt passen, möglicherweise hast du damit Recht, dass die Auflistung nur die möglichen "Master"-DSen angibt auf welchen das Paket CMS installiert werden kann, denn auf den "administrierten" (Slave) DSen wird ja das Paket selbst nicht installiert, sondern nach Einbinden in die CMS-Master-DS erfolgt nur der zusätzliche Eintrag im DSM mit dem Minimalmenü diese Slave-DS manuell zu trennen.

das CMS zeigt mir ja grundsätzlich auch alle Daten der 118 an (Pakete, Zustand Festplatte etc), aber wenn ich auf verbinden klicke, öffnet sich ein neuer Tab, der mit dem bereits gelisteten Hinweis nach kurzer Zeit geschlossen wird. Ich komme also nicht auf die DSM Oberfläche.

Ja genau und ich glaube genau diesen Part führt bei dir zu Mißverständnissen.
Zur Erklärung:
Die Master-DS, also jene die Verwaltet, meinetwegen nennen wir sie auch "Haupt-DS", nur auf dieser wird das Paket CMS installiert.
ALLE DSen die von der Haupt-DS via CMS administriert werden kommen dann autom ins CMS, wie erwähnt nur der zusätzliche Eintrag im DSM erfolgt mit der einen Schaltfläche trennen, so das man diese SLAVE DS auf ihrer Oberfläche selbst trennen könnte.
Die Steuerung erfolgt auch über die Pakete die du auf der Oberfläche der Haupt-DS von der DS118 angezeigt bekommst.
Du gehst dazu links im Menü auf der Haupt-DS auf "Aktualisieren", oben schaltest du um zwischen den beiden Arbeitsbereichen "Register DSM-Aktualisierung(en)" oder "Paketaktualisierungen".
Wählst du jetzt das Register "DSM-Aktualisierung" dann wird dir hier NICHTS angezeigt wenn deine DS bereits auf dem aktuellen DSM Stand sind!



Das hat mich am Anfang auch irretiert! HIER siehst du nur Einträge wenn eine DS im CMS-Verbund nicht die aktuelle DSM Version hat.
Nur diese eine DS würde dir angezeigt werden und du markierst die Zeile mit dieser DS und klickst auf "Aktualsieren", diese DS bekommt jetzt ihre aktuelle DSM Version heruntergeladen und installiert.
Wenn du mehrere/viele DS in der Liste hast, dann kommt die Schaltfläche "ALLE Aktualisieren" zum Einsatz, dann werden mit einem Klick ALLE DSen im CMS-Verbund mit dem neuesten DSM installiert.

Das Gleiche gilt für das Register "Paketaktualisierung"!
Du siehst bei aktuellem Softwarestand KEINE Einträge in der Liste!
Nur falls sich eine DS (oder mehrere) mit "alten" Programmpaketen im CMS Verbund befinden werden diese DSen angezeigt und in der Spalte "Paket", das jeweilige Programmpaket welches veraltet ist!

Meine DS218+ schaltet sich nur in der Nacht für die Zeit vom autom Backup ein, daher hat sie derzeit 2 "alte" Pakete, schaut dann so aus:



Nochmal WICHTIG!
So lange deine DSen im CMS-Verbund auf aktuellem DSM- und Paketstand sind, erscheinen sie NICHT in der Liste! Du siehst eine leere Seite!

Zum Thema "Verbinden", den Sinn verstehe ich hier nicht.
Du darfst nicht vergessen wenn du auf der Haupt-DS eine DS aus dem Verbund auswählst und auf "Verbinden" klickst, dann bist du dort nur als
User mit dem Namen Synology CMS eingeloggt! Du siehst dort das gleiche wie auf der Haupt-DS unter DSM und Pakete.
Du siehst als User Synology CMS nur den Standarf-DSM Desktop also mit der Grundinstallation und den Icons Paketzentrum, Systemsteuerung, Filestation und Hilfe.



AUSSER du hast dir als User Synology CMS zusätzliche Pakete angelegt.

Frage:
Wenn du dich direkt auf deiner DS118 einloggst dann muss dort schon der User "SynologyCMS" eingetragen sein, kannst du diesen auch in der DS118 sehen?
DSM > Hauptmenü > Systemsteuerung > Benutzer > Register "Benutzer" > da muss eine Zeile sein mit dem User "SynologyCMS", ABER du kannst ihn NICHT Bearbeiten! Die Schaltfläche "Bearbeiten" ist beim User SynologyCMS hellgrau/inaktiv.



Die Rechtevergabe für diesen User erfolgt wohl mit der Installation vom Paket CMS auf der Haupt-DS.

 

[Huibuu]

@Kurt-oe1kyw
Danke für die Ausführlichkeit!

In meinem CMS sieht es so aus



Wie du hier siehst, sieht es in der Haupt-DS so aus als seien alle zu administrierenden DSen verbunden und könnten administriert werden.
Wenn ich beim geschwärzten Server auf "Verbinden" klicke, dann sieht das genauso aus wie dein Bild hier

Anhang anzeigen 57743

Wenn ich bei der DS118_Backup auf "Verbinden" klicke passiert das




Der Tab (hier auto:blank; manchmal stand da auch die IP der Haupt-DS) schließt sich nach ca. 30 Sekunden.In der HauptDS wird der Vorgang mit (siehe nachfolgendes Bild) quittiert.





Ich komme wie gesagt einfach nicht in die DSM Oberfläche der DS118. Dort muss ich ja noch Backupeinstellungen vornehmen...
Gestern habe ich mir mal per SSH den LOG der Haupt-DS angeguckt.
Jedoch wird der Prozess "Verbinden" dort nicht dokumentiert. Von daher auch keine Fehlermeldung oder so...
Mir fehlt gerade auch der Ansatz wo genau der Fehler liegt. Mittlerweile glaube ich, dass die Netzwerkeinstellungen eher richtig sind und das Problem woanders zu suchen wäre?

 

[Huibuu]

Ich war nicht untätig und habe weitere Dinge ausprobiert, leider war kein Versuch von Erfolg gekrönt.

Unter anderem habe ich ein Switch zwischengeschaltet, verschiedene IP Konfigurationen probiert und nun noch die Logs des Clients sowie der FritzBox ausgelesen.

Im Log der FritzBox ist dokumentiert, dass die IP meines Clients (PC) die IP der DS118 (Backup-NAS-Direktverbindung an der DS220) sucht.
Dies deutet für mich daraufhin, dass der CMS Server (DS220) mit dem Befehl "Verbinden" im falschen LAN-Anschluss nach der DS118 sucht oder er auf der Direktverbindung keine Antwort erhält und daher dann woanders suchen geht.

Jedenfalls würde das wieder dafür sprechen, dass das Routing doch nicht ganz richtig läuft (jedenfalls sobald man das Paket "CMS" verlässt und ein neues Browserfenster geöffnet wird)

 

[Fusion]

Genau da liegt das Missverständnis.
Der CMS geht immer davon aus, dass die Slave DS selbst eine Netzwerkverbindung hat.
Wenn du also verbinden klickst versucht dein Client PC sich mit dem DSM der Slave DS zu verbinden.
Das geht eben nicht, wenn der PC und Haupt DS in 178.x und die Haupt und Slave DS in 179.x Netz sind.
Die DS ist kein Router und der Client kennt auch keine Route dorthin.
Das was du versuchst würde nur in einem Browser Prozess auf der Haupt DS funktionieren. Der Browser läuft aber auf deinem Client PC.

Du kannst die Slave DS in diesem Konstrukt nur einrichten, dann in das getrennte Netz hängen und Backups laufen lassen.
Für Updates, DSM Zugriff etc. Musst du die Slave DS immer zeitweise ins Hauptnetz 178.x hängen.

Ausweg vermutlich nur, wenn man auf der Konsole der Haupt DS das ipv4 Routing beibringt und auch im Hauptnetz passende Routen auf dem Gateway setzt.
Das macht dann aber auch die Abtrennung der Backup DS wieder sinnfrei, weil diese damit wieder aufgehoben ist.

Der CMS dient nicht dazu, dass du 'über' die Haupt DS die DMS der verbundenen Slave DS erreichst.

 

[Huibuu]

Ich ahnte so etwas. Da habe ich mich dann wohl verrannt, klang alles so einfach.

Ziel ist es die Backup-DS vom Hauptnetz zu trennen, so dass z.B. Ransomware keinen Zugang zum Backup bekommen.

Besteht noch eine andere Möglichkeit als die von dir beschriebene, so dass das administrieren und EINRICHTEN auch vom ClientPC im Hauptnetz funktionieren würde und die Sicherheit erhalten bleibt?
Vielleicht die Trennung beider Netzwerke mit VLAN´s und nur für die genannten Tätigkeiten den Client-PC dem VLAN der Backup-DS hinzuzufügen?

Für Updates, DSM Zugriff etc. Musst du die Slave DS immer zeitweise ins Hauptnetz 178.x hängen.

Wie könnte ich die SlaveDS zeitweise ins Hauptnetz hängen, wenn die IP nicht aus dem Hauptnetz ist?

 

[Fusion]

Die leichte Möglichkeit wäre, wenn du z.b. die alle im Hauptnetz betreibst und dann die Firewall der Backup DS so einstellst, dass nur Verbindungen von der Haupt DS für Backups und von einem admin Gerät möglich ist. Das sollte dann nicht der ransomware verseuchte PC sein.

Zweite Möglichkeit, wenn du vlans bei dir betreiben kannst, kann man die Trennung besser aufrecht erhalten. Wie gehabt eben den zweiten Anschluss von der Haupt und die Backup DS in eigenes vlan packen.
Normal übernimmt der Router und Firewall dann die Vermittlung zwischen den vlans.
Die bilig Variante wäre, falls nur ein vlan fähiger switch da ist, dass man dort dann eben drei ports in ein vlan hängt und untagged Verkehr ausleitet und dort 2.Lan vom Haupt, Backup, und zeitweise admin gerät anhängt.
Dazu müssen auch die einzelnen Geräte kein vlan können.

An die Backup DS ran musst ja auch nur wenn kritische Updates für das Backup Programm etc da sind. Andernfalls nur im Wiederherstellungsfall.

Kann man sicher noch drüber nachdenken was die beste Möglichkeit wäre. So wenig wie nötig hält, dauerhafter admin Zugriff gehört nicht unbedingt dazu.

 

[Huibuu]

Thema VLAN´s habe ich mich noch nicht beschäftigt und Hardware ist auch nicht da. Wenn das die praktikabelste Möglichkeit ist, werde ich aber Beides beschaffen (Hardware und Wissen).

Ich mache noch einmal zwei alternative Ideen auf und ihr sagt mir wie ihr darüber denkt:
1. Backup DS bekommt eine IP des Hauptnetzes. LAN2 der Haupt-DS bekommt ebenfalls eine IP des Hauptnetzes.
Backup DS wird für die Konfiguration (und hiermit meine ich insbesondere Ultimate Backup wegen PULL) ins Hauptnetz gehängt.
Nach der Konfiguration wird die BackupDS mit der HauptDS per LAN direkt verbunden. Die Überwachung der DS erfolgt über DSM. Die HauptDS kennt zwar den Adminzugang, in der BackupDS sind aber keine Ports freigeschaltet über die sich Ransomeware oder ähnliches verbreiten können.
Wenn nötig wird das LAN Kabel umgestöpselt und ich erreiche die BackupDS wieder.

2. Ich kaufe eine neue BackupDS (oder nutze die ausrangierte DS414) mit zwei Ports.
LAN1 - Direktverbindung zur HauptDS; LAN2 Verbindung zum Hauptnetz.
LAN2 wird manuell gezogen sobald die Installation abgeschlossen ist.
Wartung erfolgt entweder per "einstöpseln" oder über CSM

Gingen die Varianten auch, sind praktikabel und sicher? Hardware muss ich anscheinend eh anschaffen, wenn ich es möglichst einfach und sicher haben will!

 

[Huibuu]

Nachdem ich mir viele letzte Nächte mit dem Problem herumgeschlagen habe, kam mir gestern die vermutliche beste Lösung für mich in den Sinn.
Die will ich euch hier noch einmal kurz vorstellen, hinsichtlich Sicherheit "bewertet" wissen und anderen mit ähnlichen Problemen/Gedanken aufzeigen.

Ziel ist es ein Ransomware sicheres Backup zu erhalten.
Mein angedachter Weg sollt sein eine HauptDS auf einer BackupDS mit einem Pull Backup (UltimateBackup) zu sichern, da hier die HauptDS keine Zugangsdaten der BackupDS kennt, kann auch absolut kein Zugriff erfolgen.

Die BackupDS darf (als Schutzmaßnahme) nicht in Haupt-LAN sein, damit die Clients die BackupDS gar nicht erst "kennen".
Also existiert eine direkte Kabel-Verbindung zwischen Haupt- und BackupDS.
HauptLAN Port 1 xxx.xxx.123.xxx (Zugang für alle Clients)

HauptLAN Port 2 xxx.xxx.111.xxx
BackupLAN xxx.xxx.111.xxx

Da ich UltimateBackup und die ganzen Einstellungen in der DSM Oberfläche konfigurieren musste (vielleicht sind auch andere Wege möglich), brauchte ich aus dem HauptLAN Zugriff ins BackupLAN.
Hier habe ich jetzt auf der HauptDS eine Virtuelle Maschine erstellt.
Die Virtuelle Maschine hat lediglich Zugriffsberechtigung auf den LANPort2 der HauptDS und bekommt eine IP des BackupLAN.

Nun kann ich mich mit einem Client im HauptLAN mit der Virtuellen Maschine verbinden (ich mache das über die DSM Oberfläche) und dort mit einem Browser die BackupDS aufrufen und administrieren. Da die VM auch lediglich im BackupNetz unterwegs ist, brauch es hier keinen Schutz (Antiviren-Software/Firewall-Regeln/Updates) was die Arbeit lediglich auf die Einrichtung der VM beschränkt.
In der Regel soll die BackupDS autark laufen, daher wird der Zugriff eigentlich ausschließlich für die Ersteinrichtung und ggf. im Wiederherstellungsfall der Zugriff benötigt. Für Updates in der BackupDS wird CMS genutzt (es sei denn ihr haltet das nicht für sinnvoll -Frage Nr. 3)

Die ersten Tests sehen sehr vielversprechend aus, auch wenn die VM lahmt.

Bitte bewertet doch kurz das Vorgehen und beantwortet mir die nachfolgenden Fragen.

1. Wie findet ihr die Idee?

2. Bleibt der Ransomware-Schutz erhalten oder öffne ich mit der VM "neue Einfallstore" (auch für anderen Viren/Probleme)?

3. Sollte das Central Management System trotzdem zusätzlich genutzt werden oder sollte ich lieber ausschließlich die VM nutzen (auch für Updates etc), da in CMS die Benutzerdaten und Passwörter der BackupDS hinterlegt sind?

weitere OffTopic-Fragen:

4. Ist die Linux-VM weniger ressourcenfressend als Windows? Die VM lahmt schon ganz schön auf der DS220+ bei 6 GB RAM.
5. Mehr RAM = schnellere VM oder limitiert auch die CPU, die im laufenden Betrieb nahezu 90-100% ausgelastet war?
6. Wo sichert der VM-Host die VM´s hin? Ich habe nirgendwo eine Ordnerstruktur angelegt oder so?
7. Kann ich irgendwie Daten vom ClientPC per Copy-Paste in die VM übertragen? Gibt es da eine Einstellung, die ich übersehen habe?

Bin gespannt wie ihr meine Idee (wahrscheinlich zigfach irgendwo praktiziert) findet.