Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
S: Empfehlungen f. iSCSI
1 view
Skip to first unread message
Alexander Goetzenstein
Oct 8, 2022, 7:20:39 AM10/8/22
to
Hallo,
ich möchte einen externen Plattenstapel per iSCSI an einen SUSE-Rechner
anbinden. Der Rechner, an den ich das anbinden möchte, hat vier
Eth-Schnittstellen, zwei davon 10GBit, die mir geeignet erscheinen. An
eine davon soll der Plattenstapel angeschlossen werden.
Da ich bislang noch nie eine Firewall konfiguriert habe, möchte ich bei
meinen ersten Schritten möglichst so vorgehen, dass es nicht nur
irgendwie funktioniert, sondern dass auch ein Anderer sich auf Anhieb
zurechtfindet, also möglichst geschriebene und ungeschriebene Standards
verwenden.
Auf den ersten Blick könnte ich einfach die Zone 'block' der
Eth-Schnittstelle zuweisen und in der Zone 'block' den Dienst
iscsi-target erlauben. Alternativ könnte ich die ports 3260/TCP und
3260/UDP freigeben. Zwei Dinge lassen mich zweifeln:
1.: "block" klingt nach "alles bleibt zu"; man würde vielleicht nicht
erwarten, dass darin etwas freigegeben ist. Wäre eine andere Zone besser
geeignet? Oder sollte ich eine neue Zone dafür anlegen, und falls ja:
wie zu benennen?
2.: Sollte vorzugsweise der Dienst oder die Ports freigegeben werden,
oder beides?
Oder macht "man" das am besten ganz anders?
--
Gruß
Alex
ich möchte einen externen Plattenstapel per iSCSI an einen SUSE-Rechner
anbinden. Der Rechner, an den ich das anbinden möchte, hat vier
Eth-Schnittstellen, zwei davon 10GBit, die mir geeignet erscheinen. An
eine davon soll der Plattenstapel angeschlossen werden.
Da ich bislang noch nie eine Firewall konfiguriert habe, möchte ich bei
meinen ersten Schritten möglichst so vorgehen, dass es nicht nur
irgendwie funktioniert, sondern dass auch ein Anderer sich auf Anhieb
zurechtfindet, also möglichst geschriebene und ungeschriebene Standards
verwenden.
Auf den ersten Blick könnte ich einfach die Zone 'block' der
Eth-Schnittstelle zuweisen und in der Zone 'block' den Dienst
iscsi-target erlauben. Alternativ könnte ich die ports 3260/TCP und
3260/UDP freigeben. Zwei Dinge lassen mich zweifeln:
1.: "block" klingt nach "alles bleibt zu"; man würde vielleicht nicht
erwarten, dass darin etwas freigegeben ist. Wäre eine andere Zone besser
geeignet? Oder sollte ich eine neue Zone dafür anlegen, und falls ja:
wie zu benennen?
2.: Sollte vorzugsweise der Dienst oder die Ports freigegeben werden,
oder beides?
Oder macht "man" das am besten ganz anders?
--
Gruß
Alex
Jens Hektor
Oct 27, 2022, 1:43:31 PM10/27/22
to
Am 08.10.22 um 13:20 schrieb Alexander Goetzenstein:
> meinen ersten Schritten möglichst so vorgehen, dass es nicht nur
> irgendwie funktioniert, sondern dass auch ein Anderer sich auf Anhieb
> zurechtfindet, also möglichst geschriebene und ungeschriebene Standards
> verwenden.
Guter Ansatz.
> Auf den ersten Blick könnte ich einfach die Zone 'block' der
> Eth-Schnittstelle zuweisen und in der Zone 'block' den Dienst
> iscsi-target erlauben. Alternativ könnte ich die ports 3260/TCP und
> 3260/UDP freigeben. Zwei Dinge lassen mich zweifeln:
>
> 1.: "block" klingt nach "alles bleibt zu"; man würde vielleicht nicht
> erwarten, dass darin etwas freigegeben ist. Wäre eine andere Zone besser
> geeignet? Oder sollte ich eine neue Zone dafür anlegen, und falls ja:
> wie zu benennen?
Man sollte auf jeden Fall noch ICMP zulassen.
> 2.: Sollte vorzugsweise der Dienst oder die Ports freigegeben werden,
> oder beides?
Nun ja. "Dienste" ist eine Abstraktionsschicht.
Letztendlich filtern Paketfilter immer auf Layer-3/4.
Für genaueres müsste man das Anwendungsszenario und die Konfiguration
des Restes der Maschine berücksichtigen.
> Da ich bislang noch nie eine Firewall konfiguriert habe, möchte ich bei
herzlich willkommen. An dem Punkt waren hier alle mal.
> meinen ersten Schritten möglichst so vorgehen, dass es nicht nur
> irgendwie funktioniert, sondern dass auch ein Anderer sich auf Anhieb
> zurechtfindet, also möglichst geschriebene und ungeschriebene Standards
> verwenden.
> Auf den ersten Blick könnte ich einfach die Zone 'block' der
> Eth-Schnittstelle zuweisen und in der Zone 'block' den Dienst
> iscsi-target erlauben. Alternativ könnte ich die ports 3260/TCP und
> 3260/UDP freigeben. Zwei Dinge lassen mich zweifeln:
>
> 1.: "block" klingt nach "alles bleibt zu"; man würde vielleicht nicht
> erwarten, dass darin etwas freigegeben ist. Wäre eine andere Zone besser
> geeignet? Oder sollte ich eine neue Zone dafür anlegen, und falls ja:
> wie zu benennen?
> 2.: Sollte vorzugsweise der Dienst oder die Ports freigegeben werden,
> oder beides?
Letztendlich filtern Paketfilter immer auf Layer-3/4.
Für genaueres müsste man das Anwendungsszenario und die Konfiguration
des Restes der Maschine berücksichtigen.
Marco Moock
Oct 27, 2022, 1:59:49 PM10/27/22
to
Am 27.10.2022 um 19:43:29 Uhr schrieb Jens Hektor:
> Man sollte auf jeden Fall noch ICMP zulassen.
Auf jeden Fall, denn das ist u.a. für die Path MTU-Discovery zuständig.
> Man sollte auf jeden Fall noch ICMP zulassen.
Um ping-Floods zu vermeiden kann man ggf. eingehende ICMP-Echo-Request
limitieren.
> > 2.: Sollte vorzugsweise der Dienst oder die Ports freigegeben
> > werden, oder beides?
>
> Nun ja. "Dienste" ist eine Abstraktionsschicht.
auch auf anderen Ports laufen lassen. Wenn "Dienst" bei der FW
bedeutet, dass nach dem Protokoll selbst gefiltert wird statt dem Port,
ist das Verhalten natürlich anders.
> > Letztendlich filtern Paketfilter immer auf Layer-3/4.
Firewalls können meist nach MAC-Adressen, IP-Adressen, ganzen
Protokollen und Port-Nummern (UDP/TCP) filtern.
Kay Martinen
Oct 27, 2022, 3:10:19 PM10/27/22
to
Am 08.10.22 um 13:20 schrieb Alexander Goetzenstein:
> Hallo,
> ich möchte einen externen Plattenstapel per iSCSI an einen SUSE-Rechner
> anbinden. Der Rechner, an den ich das anbinden möchte, hat vier
> Eth-Schnittstellen, zwei davon 10GBit, die mir geeignet erscheinen. An
> eine davon soll der Plattenstapel angeschlossen werden.
>
> Da ich bislang noch nie eine Firewall konfiguriert habe, möchte ich bei
> ich möchte einen externen Plattenstapel per iSCSI an einen SUSE-Rechner
> anbinden. Der Rechner, an den ich das anbinden möchte, hat vier
> Eth-Schnittstellen, zwei davon 10GBit, die mir geeignet erscheinen. An
> eine davon soll der Plattenstapel angeschlossen werden.
>
> Da ich bislang noch nie eine Firewall konfiguriert habe, möchte ich bei
> Oder macht "man" das am besten ganz anders?
Meine Erste Frage ist da, Wie weit sind denn Plattenstapel und SuSE
Rechner entfernt? Und ist da eine Direkte 10G Verbindung vorhanden,
vermutlich mit Glasfasern? Oder läuft das über Switches mit normalem
anderen Netzwerk-Traffic?
Was spricht eigentlich dagegen den 10G Port des Rechners direkt und
Ausschließlich mit deinem Plattenstapel zu verbinden? Dann brauchst du;
nach meinem dafürhalten; überhaupt keine Firewall.
"Plattenstapel" ist auch sehr vage. Ist das ein SAN oder ein NAS oder
einfach ein weiterer Rechner mit vielen Platten die dieser per iscsi
raus reicht - an einem nicht-exklusivem Netzwerk-Port?
Da dein SuSE PC vier NICs und davon zwei mal 10G haben soll gehe ich mal
stark davon aus das es kein Desktop ist sondern eher ein Server oder?
Du kannst m.E. die für iscsi nötigen Ports erlauben, die IP deines
Plattenstaplers auch und wenn sonst nichts ist einfach alles andere
außer icmp verbieten - vor allem von allen anderen Adressen außer der IP
die du haben willst.
Ich hab iscsi noch nicht verwendet und kann nicht sagen welche Ports
dafür nötig sind aber nebenan steht dazu ja schon mehr.
Ｂｙｅ／
／Ｋａｙ
--
"Kann ein Wurstbrot die Welt retten?" :-)
Alexander Goetzenstein
Oct 28, 2022, 9:37:13 AM10/28/22
to
Hallo,
Am 27.10.22 um 21:01 schrieb Kay Martinen:
den Plattenplatz per iSCSI bereitzustellen) ist direkt per Ethernet
angeschlossen. Die Firewall ist derzeit komplett deaktiviert, was mir
missfällt, weil der Server ja auch noch andere Ethernet-Schnittstellen
bedient. Mit der Schnittstelle zum NAS will ich anfangen, da dieser zum
Betrieb des Servers erforderlich ist, denn u.a. liegen die /home
-Verzeichnisse darauf.
> "Plattenstapel" ist auch sehr vage. Ist das ein SAN oder ein NAS oder
> einfach ein weiterer Rechner mit vielen Platten die dieser per iscsi
> raus reicht - an einem nicht-exklusivem Netzwerk-Port?
Das NAS ist direkt, also ohne Umweg über einen Switch angeschlossen.
> Da dein SuSE PC vier NICs und davon zwei mal 10G haben soll gehe ich mal
> stark davon aus das es kein Desktop ist sondern eher ein Server oder?
Es ist eine Pizza-Box, die nichts anderes zu tun hat / haben soll als
den Plattenplatz bereitzustellen, Backup zu steuern und artverwandte
Sachen. In der Hoffnung, nichts vergessen zu haben, werden LAN-seitig
rsync und ssh benötigt, NAS-seitig nur iSCSI.
Bevor die Frage kommt, warum ich das nicht komplett dem NAS überlasse:
beim NAS bin ich weit weniger flexibel und von dem abhängig, was der
Hersteller und Drittanbieter mir anbieten. Unison und borg wären
Beispiele, bei denen es hakt, und es gibt noch mehr.
Folgen soll eine VM, die per cron nachts startet, wobei die allgemeine
LAN-Schnittstelle geschlossen und der zweite 10G-Port für die VM
geöffnet wird. Die VM soll dann mit borg ein Backup auf ein zweites NAS
machen. Nach Abschluss des Backups soll die VM wieder herunterfahren,
dabei den zweiten 10G-Port schließen und den allgemeinen LAN-Port wieder
öffnen, so im Groben meine Idee. Im ersten Schritt will ich den
Ist-Zustand auf einen korrekten Stand bringen, wozu eben auch eine
vernünftige Firewalleinstellung gehört. Da möchte ich mich allgemeinen
Konventionen anschließen.
--
Gruß
Alex
Am 27.10.22 um 21:01 schrieb Kay Martinen:
> Am 08.10.22 um 13:20 schrieb Alexander Goetzenstein:
>> Hallo,
>> ich möchte einen externen Plattenstapel per iSCSI an einen SUSE-Rechner
>> anbinden. Der Rechner, an den ich das anbinden möchte, hat vier
>> Eth-Schnittstellen, zwei davon 10GBit, die mir geeignet erscheinen. An
>> eine davon soll der Plattenstapel angeschlossen werden.
>>
>> Da ich bislang noch nie eine Firewall konfiguriert habe, möchte ich bei
>
>> Oder macht "man" das am besten ganz anders?
>
> Meine Erste Frage ist da, Wie weit sind denn Plattenstapel und SuSE
> Rechner entfernt? Und ist da eine Direkte 10G Verbindung vorhanden,
> vermutlich mit Glasfasern? Oder läuft das über Switches mit normalem
> anderen Netzwerk-Traffic?
>
> Was spricht eigentlich dagegen den 10G Port des Rechners direkt und
> Ausschließlich mit deinem Plattenstapel zu verbinden? Dann brauchst du;
> nach meinem dafürhalten; überhaupt keine Firewall.
der Plattenstapel (ein Synology NAS, das keine andere Aufgabe hat, als
>> Hallo,
>> ich möchte einen externen Plattenstapel per iSCSI an einen SUSE-Rechner
>> anbinden. Der Rechner, an den ich das anbinden möchte, hat vier
>> Eth-Schnittstellen, zwei davon 10GBit, die mir geeignet erscheinen. An
>> eine davon soll der Plattenstapel angeschlossen werden.
>>
>> Da ich bislang noch nie eine Firewall konfiguriert habe, möchte ich bei
>
>> Oder macht "man" das am besten ganz anders?
>
> Meine Erste Frage ist da, Wie weit sind denn Plattenstapel und SuSE
> Rechner entfernt? Und ist da eine Direkte 10G Verbindung vorhanden,
> vermutlich mit Glasfasern? Oder läuft das über Switches mit normalem
> anderen Netzwerk-Traffic?
>
> Was spricht eigentlich dagegen den 10G Port des Rechners direkt und
> Ausschließlich mit deinem Plattenstapel zu verbinden? Dann brauchst du;
> nach meinem dafürhalten; überhaupt keine Firewall.
den Plattenplatz per iSCSI bereitzustellen) ist direkt per Ethernet
angeschlossen. Die Firewall ist derzeit komplett deaktiviert, was mir
missfällt, weil der Server ja auch noch andere Ethernet-Schnittstellen
bedient. Mit der Schnittstelle zum NAS will ich anfangen, da dieser zum
Betrieb des Servers erforderlich ist, denn u.a. liegen die /home
-Verzeichnisse darauf.
> "Plattenstapel" ist auch sehr vage. Ist das ein SAN oder ein NAS oder
> einfach ein weiterer Rechner mit vielen Platten die dieser per iscsi
> raus reicht - an einem nicht-exklusivem Netzwerk-Port?
> Da dein SuSE PC vier NICs und davon zwei mal 10G haben soll gehe ich mal
> stark davon aus das es kein Desktop ist sondern eher ein Server oder?
den Plattenplatz bereitzustellen, Backup zu steuern und artverwandte
Sachen. In der Hoffnung, nichts vergessen zu haben, werden LAN-seitig
rsync und ssh benötigt, NAS-seitig nur iSCSI.
Bevor die Frage kommt, warum ich das nicht komplett dem NAS überlasse:
beim NAS bin ich weit weniger flexibel und von dem abhängig, was der
Hersteller und Drittanbieter mir anbieten. Unison und borg wären
Beispiele, bei denen es hakt, und es gibt noch mehr.
Folgen soll eine VM, die per cron nachts startet, wobei die allgemeine
LAN-Schnittstelle geschlossen und der zweite 10G-Port für die VM
geöffnet wird. Die VM soll dann mit borg ein Backup auf ein zweites NAS
machen. Nach Abschluss des Backups soll die VM wieder herunterfahren,
dabei den zweiten 10G-Port schließen und den allgemeinen LAN-Port wieder
öffnen, so im Groben meine Idee. Im ersten Schritt will ich den
Ist-Zustand auf einen korrekten Stand bringen, wozu eben auch eine
vernünftige Firewalleinstellung gehört. Da möchte ich mich allgemeinen
Konventionen anschließen.
--
Gruß
Alex
Alexander Goetzenstein
Oct 28, 2022, 9:43:26 AM10/28/22
to
Hallo Jens,
Danke, ICMP wäre für Funktionsprüfung oder Fehlersuche gedacht?
Anwendungsszenario und Konfig habe ich in
<36b3fa08-66ae-1a47...@alexander-goetzenstein.my-fqdn.de>
beschrieben; um nicht alles doppelt zu haben, verweise ich einfach mal
darauf.
Am 27.10.22 um 19:43 schrieb Jens Hektor:
--
Gruß
Alex
Danke, ICMP wäre für Funktionsprüfung oder Fehlersuche gedacht?
Anwendungsszenario und Konfig habe ich in
<36b3fa08-66ae-1a47...@alexander-goetzenstein.my-fqdn.de>
beschrieben; um nicht alles doppelt zu haben, verweise ich einfach mal
darauf.
Am 27.10.22 um 19:43 schrieb Jens Hektor:
Gruß
Alex
Marco Moock
Oct 28, 2022, 9:52:04 AM10/28/22
to
Am 28.10.2022 schrieb Alexander Goetzenstein
<alexander_g...@web.de>:
> Danke, ICMP wäre für Funktionsprüfung oder Fehlersuche gedacht?
Fehlermeldungen, z.B. wenn ein System nicht erreichbar ist.
So sieht der Absender, was das Problem ist.
Gerade bei MTU path discovery (ICMP packet too big) extrem wichtig, weil
sonst ein Timeout entsteht, den keiner lokalisieren kann.
<alexander_g...@web.de>:
> Danke, ICMP wäre für Funktionsprüfung oder Fehlersuche gedacht?
So sieht der Absender, was das Problem ist.
Gerade bei MTU path discovery (ICMP packet too big) extrem wichtig, weil
sonst ein Timeout entsteht, den keiner lokalisieren kann.
0 new messages