Rackstation: SMB-Shares an IPs/LAN-Ports binden

[vamos_ole]

Hallo,

ich möchte folgende Konfiguration an meine Rackstation RS18017xs+ verwirklichen:

LAN 1: IP 192.168.2.50 <- DSM
LAN 2: IP 192.168.2.51 <- smb share a, soll aus dem LAN erreichbar sein mit \\192.168.2.51\sharea
LAN 3: IP 192.168.2.52 <- smb share b, soll aus dem LAN erreichbar sein mit \\192.168.2.52\shareb
LAN 4: IP 192.168.2.53 <- smb share c, soll aus dem LAN erreichbar sein mit \\192.168.2.53\sharec

Ist das möglich? Die Zuweisung der IPs zu den Ports ist kein Problem, die Verknüpfung der shares mit den IPs kriege ich nicht hin. Danke im Voraus!

 

[blurrrr]

Zuweisung von IPs zu Ports? Wenn, handelt es sich erstmal um den "listen"-Eintrag in der smb.conf, wo Du "global" bestimmt, auf welchen Interfaces der Samba-Dienst zur Verfügung steht. Dazu gibt es (meines wissens auch nur "global") die Möglichkeit von Einträgen bzw. "hosts deny" und hosts allow". Letzteres speziell für bestimmte "shares" wäre mir nicht bekannt, kann man aber sicherlich mal ausprobieren. Über die GUI wird es wohl eher nichts, von daher müsstest Du die share-Definition innerhalb der smb.conf anpassen. Wenn danach "garnix" mehr geht (aufgrund fehlerhafter Syntax z.B.), Änderungen wieder rückgängig machen (oder zuvor kopierte Datei wieder zurückkopieren).

Alternativ kannst Du aber auch hingehen und die entsprechenden Freigaben für User ohne Berechtigungen ausblenden.

Das mit den IP-Adressen nach Share macht für mich aber herzlichst wenig Sinn, da es noch nichtmals andere Netze sind... Was genau willst Du damit eigentlich bezwecken (ausser dem oben genannten)?

 

[vamos_ole]

Mit der Zuweisung der IPs zu Ports meine ich, dass ich per DSM problemlos jedem Ethernetport eine IP zuweisen kann, über den er dann ansprechbar ist. Meine Idee war jetzt, shares den einzelnen IPs zuzuordnen, so dass halt Share A nur über den Ethernetport A zu erreichen ist.
Der Hintergrund des Ganzen ist, dass ich eine bestehende Konfiguration von einem EMC-System (da geht das ganze nämlich problemlos) auf ein Rackstation-System übertragen will. Das Ganze hat auch nichts mit Berechtigungen zu tun, sondern eher mit dem Vorhandensein verschiedener Pfade in meinen GPOs, die ich ungern umbauen würde.
Unsere Benutzerprofile liegen hier auf Share A, Daten liegen auf Share B, Deployment läuft über Share C. Diese werden an verschiedenen Stellen per IP angesprochen.

 

[blurrrr]

Achso, sorry, mein Fehler - hatte noch nicht genug Kaffee

Okay, dann verstehe ich aber Dein Problem ehrlich gesagt nicht so wirklich... Wenn alle IPs/Ports von Samba genutzt werden, hast Du doch genau "das". Die "Berechtigungen" für die Shares sind halt noch ein anderes Thema. Zwar kannst Du jedes Share über jede IP ansprechen, musst Du aber nicht. Entweder "kannst" Du dann 1 IP für den Zugriff auf die Shares nutzen, oder belieblig durch die Gegend würfeln.

Das EMC-Gerät wird sich vermutlich auch nur eines Samba-Dienstes bedienen, so dass auf selbigem Gerät ebenfalls eine smb.conf existieren müsste. Diese könntest Du Dir ja auch mal anschauen

 

[vamos_ole]

Richtig, da habe ich den Wald vor lauter Bäumen nicht gesehen. Da die Berechtigungen eh auf Ordnerebene geregelt werden, ist es ja egal, über welche der IPs man das share anspricht. Danke für den Denkanstoß, läuft.

 

[blurrrr]

Kannste natürlich noch für die Auslastung trennen (oder einfach einen Trunk/Bond/LAG) bauen. Allerdings kann ich das Theater trotz allem nicht wirklich nachvollziehen... Du hast doch schon GPOs... Klick.. Klick... für tausende von Usern geändert? Naja, egal... wat läuft, dat läuft und dat is die Hauptsache

 

[NSFH]

Um die Performance zu erhöhen habe ich auch zB eine der 4 Schnittstellen direkt einem Videoschnittsytem zugeordnet, damit sich dieses aus dem Switchverkehr heraus hält. Zwei Ports der Syno laufen als Trunk auf je einem Switch auf, was die Schnittstelle zwischen den Switchen entlastet hat. Port 4 geht übrigens auf die Fw.

 

[noVa20]

Hallo Zusammen,

Ich würde den Beitrag gerne aufgreifen und fragen ob jemand dies so umsetzen konnte? Wir haben folgenden Usecase dafür:

2 Interfaces ->
1x 192.168.100.20 -> Share A
1 x 192.168.200.30 -> Share B

Ziel soll es sein, dass Share A nur während dem Backupfenster erreichbar ist und sonst nicht. Dies würden wir realisieren indem wir den Switchport zeitgesteuert auf DOWN stellen.
Share B soll aber ganz normal über den Tag erreichbar bleiben. jedoch soll es nicht möglich sein über das Interface 200.30 den Share A zu erreichen auch wenn der User bekannt ist.
Damit soll verhindert werden, dass wenn sich im Netz durch den Tag was ausbreiten sollte, die Backupdaten davon betroffen werden oder Share A bei einer Infektion gezielt offline genommen werden kann.

Für jeglichen Input bin ich euch dankbar.

Beste Grüsse
noVa20

 

[blurrrr]

Hi.

1) Antwort steht schon oben
2) Was soll der Blödsinn mit dem "Port-Shutdown" (zumal das Ziel das gleiche bleibt), hast Du sowas schon mal woanders in freier Wildbahn gesehen, oder habt ihr euch das so ganz kühn so ausgedacht?
3) Überdenke das Backup-Konzept vielleicht nochmal

Antwort 3 ist übrigens die ernst gemeinteste

 

[NSFH]

@nova20: Sorry, aber welch unsinniges Konstrukt, welches auch überhaupt nicht vor Schadsoftware schützt.
Schau dir mal diese Diskussion an, wenn es um Backups geht.
https://www.synology-forum.de/showt...e-Eure-Hyperbackups-nicht-verschuesseln/page5

 

[noVa20]

Hi blurrrr

Danke für deine Mühe und die weniger konstruktiven Antworten

1) Wenn die Antwort für meine Anfrage oben stehen würde, hätte ich mich dieser bedient
2) Es geht um eine physikalische Trennung von Quelle und Ziel -> deshalb das Theater mit dem Port-Shutdown, und nein - Wenn das Share-IP Mapping funktionieren würde ist es nicht das selbe Ziel aus SMB Sicht. Und ja wie oben erwähnt gibt es Geräte von EMC wie auch von andern Herstellern die gezielt das so umsetzen.
3) Danke für den Hinweis! Nicht ohne Grund will ein "offline" Backup über diesen Weg realisieren...

noVa20

 

[noVa20]

@NSFH

Wieso bist du der Meinung das dies nicht vor Schadenssoftware Schützt? Damit bewirke ich, dass das Backupziel nur über eine IP erreichbar ist und ausserhalb des Backupfensters offline ist. Das selbe erreiche ich auch mit einem Tape oder einer Disk die ich manuell anschliessen muss. Hier ist jedoch die Anforderung, dass das Online-Archiv über Share B aus einem eigenen Subnetz erreichbar bleiben soll.
Backupstrategieen sind mir durchaus bekannt, jedoch geht es da um EIN Device mit über 200TB Kapazität welches für Archiv wie auch Onsite-Backup verwendet werden soll. In diesem Punkt gebe ich dir und deinem Vorredner recht, wenn ich das geplant hätte, hätte ich zwei Geräte geordert und das von Anfang an separat behandelt - leider soll aus der bestehenden Umgebung ein sicheres Konzept entstehen. Deswegen meine Frage oben.

noVa20

 

[blurrrr]

"Es geht um eine physikalische Trennung von Quelle und Ziel" Also sorry, aber Quelle und Ziel bleiben ja wohl anscheinend gleich, auch wenn Du andere Ports nutzt. Sicherlich kann man auf ACLs zurückgreifen (in Bezug auf die Shares) und bestimmt auch auf Firewall-Regeln (in Bezug auf die Ports/VLANs/IPs), aber eine "physikalische" Trennung sieht dann doch anders aus, die Gerätschaften bleiben ja die gleichen und sind auch dauerhaft verbunden. Was Du bei dem ganzen Szenario anscheinend vergessen hast, sind schlichte Themen wie Rechte-Eskalationen, etc. ... Physikalische Trennung? Auf jeden Fall! Aber so irgendwie... nicht.

Archiv UND Backup direkt zusammen ist natürlich auch Klasse, da dann im schlimmsten Fall direkt sowohl das Backup als auch das Archiv dahin wäre...

"leider soll aus der bestehenden Umgebung"... da fällt mir jetzt grade nur ein Sprichwort zu ein, aber das lass ich hier lieber, ist nicht ganz sauber Aber ggf. kann man eben kein Gold daraus machen... Eine andere Alternative wäre ggf. noch auf der bestehenden Kiste einfach 2x vDSM zu nutzen (1x Archiv, 1x Backup), aber das ist auch wieder nur so eine pseudo-physikalische Trennung. Ich denke doch mal, dass das Backup den meisten Speicher benötigen wird und das Archiv (in welchem sich ja tendentiell nicht mehr groß was ändern sollte, ausser, dass ggf. jahresbasiert etwas neues hinzu kommt) nur einmal gesichert werden muss (oder bei Neuerungen halt, also tendentiell auch nicht so oft). Wäre es da nicht ggf. noch eine Möglichkeit (um halt den Invest auch gering zu halten), dass man für das Archiv noch etwas "kleines" anschafft und die dicke Kiste eben die Backup-Appliance ist?