iptables + IDE-Raid

Hallo Peter!

Die Netfilter-Dokumentation ist recht gut, enthält die Infos speziell zum
Thema Prerouting und Postrouting aber ziemlich zwischen den Zeilen
versteckt. Daraus ist nicht leicht erkenntlich wieso sich genau dieses
Verhalten bei Luigi manifestiert (Thema: Postrouting ACCEPT / Prerouting
DROP).

Das hat nicht viel mit rumprobieren zu tun ;o)

Ich habe mir die Sache nochmal kurz angesehen. Meine Erinnerungen gehen da
leider auf ipchains und ipfwadm zurück... deshalb war ich mir auch nicht
mehr so sicher. Es gibt einen einzigen Hinweis auf der aktuellen
Netfilter-Seite (wenigstens was ich persönlich zum Thema finden konnte) und
zwar im NAT-HOWTO Kapitel 5 und 5.1.

Wenn jemand genaueres zum Thema findet, sagt mir bescheid!

Übrigens: ich habe mir kurz nochmal die Sache mit dem IDE-Raid angesehen.
Effektiv werden als richtiges IDE-HW-Raid nur 3ware-Systeme von einem
ungepatchten Linux-Kernel unterstützt.

Cheers,

Gunny

Günther Mair
Internet Engineer

ENERGIS Italia GmbH
Pfarrhofstrasse 60/A
I-39100 Bozen (BZ)
Tel.: +39 0471 254000
Fax: +39 0471 251617
Email: guenther.mair(a)energis.it
Web: http://www.energis.it

                    Peter Warasin
                    <Peter.Warasin(a)darkr An: lugbz-list(a)lugbz.org
                    ealms.org> Kopie: guenther.mair(a)energis.it
                    Gesendet von: Thema: Re: Antwort: [Lugbz-list] iptables
                    lugbz-list-admin(a)lug
                    bz.org
                                                                                                                                       
                    25.05.2003 13:06
                    Bitte antworten an
                    lugbz-list
                                                                                                                                       
hallo

Die filter-tabelle ist die einzige, die grundsatzlich nichts am
Paket verändern kann. Die anderen beiden schon.
Ich vermute, dass die Ketten aller Tabellen hintereindander
abgearbeitet werden.
Das würde einiges erklären.

bevor ihr da rumprobiert um sachen rauszufinden:
auf www.netfilter.org gibts genug dokumentation wo genau beschrieben ist
wie, welche chains fuer was gebraucht werden und wie das alles
funktioniert.
gibts sogar in mehreren sprachen und in mehreren formaten.

da steht z.b wie die pakete die filter passieren:
http://www.netfilter.org/documentation/HOWTO/de/packet-filtering-HOWTO.html#toc6

hallo

Die Netfilter-Dokumentation ist recht gut, enthält die Infos speziell zum
Thema Prerouting und Postrouting aber ziemlich zwischen den Zeilen
versteckt. Daraus ist nicht leicht erkenntlich wieso sich genau dieses
Verhalten bei Luigi manifestiert (Thema: Postrouting ACCEPT / Prerouting
DROP).

in *der* howto ist auch nur beschrieben wie packet filtering
funktioniert. das hat eigentlich nur was mit der filter table zu tun. in
der nat table sollen nur nat-spezifische eintraege rein. aus diesem
grund soll da auch nicht gefiltert werden. d.h man soll da auch nicht
default droppen.

ich kann mir zwar nicht erklaeren, warum die dhcp-anfrage ueberhaupt zum
dhcp server durchgekommen ist, aber weshalb die antwort nicht
zurueckkommen konnte schon:
der prerouting-chain wird nur beim verbindungsaufbau durchlaufen, danach
nicht mehr. allerdings muss das paket fuer den verbindungsaufbau durch
den prerouting-chain. in dieser wird so ein verbindungsaufbau aber nicht
durch eine accept-rule erlaubt.

aus diesem grund kann man auch keine kde-programme mehr starten, bzw
sich bei kde nicht einloggen. ein verbindungsaufbau zu localhost
durchlaeuft ebenso die prerouting-chain und wird da durch default drop
geblockt.

man muesste genau dieselben rules, welche in der filter-table drin sind
auch in die prerouting-chain der nat und mangle table einfuegen
(warscheinlich auch noch in die anderen chains), damit es funktionieren
wuerde.

allerdings macht das wenig sinn (ausser in ganz bestimmten situationen),
da ja die filter-table bereits *filtert*. das muss nicht in der mangle
und nat table auch noch zusaetzlich geschehen.

deshalb: chains der mangle und nat-table nicht auf default-policy drop
setzen um zu filtern!

Das hat nicht viel mit rumprobieren zu tun ;o)

das war darauf bezogen, dass luigi schreibt er hat ein paar sachen
rausgefunden und dass er vermutet dass alle ketten hintereinander
abgearbeitet werden.
in der netfilter dokumentation (alle howtos, tutorials, faq, usw) steht
das schon genau beschrieben wie die pakete die chains durchlaufen.

Ich habe mir die Sache nochmal kurz angesehen. [..] Es gibt einen einzigen Hinweis auf der aktuellen
Netfilter-Seite (wenigstens was ich persönlich zum Thema finden konnte) und
zwar im NAT-HOWTO Kapitel 5 und 5.1.
Wenn jemand genaueres zum Thema findet, sagt mir bescheid!

bzgl?

es gibt da noch massenweise tutorials. auch gibts z.b ein interview mit
harald welte auf www.kernelnewbies.org (unter irc-logs), wo er netfilter
ein bisschen erklaert.
aber ich glaube das was er da sagt ist auch schon in den dokus behandelt
worden.

Übrigens: ich habe mir kurz nochmal die Sache mit dem IDE-Raid angesehen.
Effektiv werden als richtiges IDE-HW-Raid nur 3ware-Systeme von einem
ungepatchten Linux-Kernel unterstützt.

ich weiss. ich wuerde nie ein ide-raid im produktionsbereich
vorschlagen. (leider lassen sich viele aufgrund der teuren scsi-geraete
dazu verleiten)
das mit 3ware ist interessant.

auch deshalb wuerde ich keine ide-platten vorschlagen weil ide-platten
*fuer server* nicht gebaut worden sind. die sollten eigentlich nicht 24h
am tag laufen, das halten ide-platten eigentlich laut spezifikation
nicht aus (auch wenn man meistens trotzdem keine probleme hat). fuer
sowas gibts scsi.
im desktopbereich ists natuerlich was anderes.

peter

hallo

Wenn jemand genaueres zum Thema findet, sagt mir bescheid!

hab das interview auf kernelnewbies rausgesucht..
da stehts doch besser erklaert als in den howtos:

<LaForge> PART 1 - netfilter basics
<LaForge> I was talking about these hooks at particular points in the network stack.
<LaForge> I'm going to concentrate on IPv4, as this seems to be the most important case :slight_smile:
<LaForge> --->[1]--->[ROUTE]--->[3]--->[4]--->
<LaForge> | ^
<LaForge> | |
<LaForge> | [ROUTE]
<LaForge> v |
<LaForge> [2] [5]
<LaForge> | ^
<LaForge> | |
<LaForge> v |
<LaForge>
<LaForge> on the left hand, you have incoming packets, coming from the network
<LaForge> on the right hand, outgoing packets are leaving to the network
<LaForge> on the bottom of the picture is our local machine, the local userspace processes.
<LaForge> the 5 hooks are called:
<LaForge> 1 NF_IP_PRE_ROUTING
<LaForge> 2 NF_IP_LOCAL_IN
<LaForge> 3 NF_IP_FORWARD
<LaForge> 4 NF_IP_POST_ROUTING
<LaForge> 5 NF_IP_LOCAL_OUT
<LaForge> so let's view at the path a packet goes while being forwarded by our machine:
<LaForge> Firs it comes off the wire, it passes hook #1. The routing decision is made,
<LaForge> it passes hook #3 (forward), passes hook #4 (post_routing) and leaves off to the network again.
<LaForge> If we look on packets which have a local destionation (are locally terminated an are not routed), the following path:
<LaForge> packet comes off the wire
<LaForge> packet hits hoo #1 (pre_routing)
<LaForge> routing decision decides that packet is local
<LaForge> packet hits hook #2 (local_in)
<LaForge> packet hits local process
<LaForge>
<LaForge> If we look at a locally-originated packet:
<LaForge> packet is generated by local process at the bottom
<LaForge> packet hits hook #5 (local_out)
<LaForge> routing code decides where to route the packet
<LaForge> packet passes hook #4 (post_routing)
<LaForge> packet hits the wire of the network

das interview ist auf:
http://www.kernelnewbies.org/documents/irclogs/netfilter.log

da sind dann noch mehr solcher interviews und dokumente:
http://www.kernelnewbies.org/documents/

peter

Hallo

hallo

> Wenn jemand genaueres zum Thema findet, sagt mir bescheid!

hab das interview auf kernelnewbies rausgesucht..
da stehts doch besser erklaert als in den howtos:

<LaForge> PART 1 - netfilter basics
<LaForge> I was talking about these hooks at particular points in
the network stack. <LaForge> I'm going to concentrate on IPv4, as
this seems to be the most important case :slight_smile: <LaForge>
--->[1]--->[ROUTE]--->[3]--->[4]--->
<LaForge> | ^
<LaForge> | |
<LaForge> | [ROUTE]
<LaForge> v |
<LaForge> [2] [5]
<LaForge> | ^
<LaForge> | |
<LaForge> v |
<LaForge>
<LaForge> on the left hand, you have incoming packets, coming
from the network <LaForge> on the right hand, outgoing packets
are leaving to the network <LaForge> on the bottom of the picture
is our local machine, the local userspace processes. <LaForge>
the 5 hooks are called:
<LaForge> 1 NF_IP_PRE_ROUTING
<LaForge> 2 NF_IP_LOCAL_IN
<LaForge> 3 NF_IP_FORWARD
<LaForge> 4 NF_IP_POST_ROUTING
<LaForge> 5 NF_IP_LOCAL_OUT
<LaForge> so let's view at the path a packet goes while being
forwarded by our machine: <LaForge> Firs it comes off the wire,
it passes hook #1. The routing decision is made, <LaForge> it
passes hook #3 (forward), passes hook #4 (post_routing) and
leaves off to the network again. <LaForge> If we look on packets
which have a local destionation (are locally terminated an are
not routed), the following path: <LaForge> packet comes off the
wire
<LaForge> packet hits hoo #1 (pre_routing)
<LaForge> routing decision decides that packet is local
<LaForge> packet hits hook #2 (local_in)
<LaForge> packet hits local process
<LaForge>
<LaForge> If we look at a locally-originated packet:
<LaForge> packet is generated by local process at the bottom
<LaForge> packet hits hook #5 (local_out)
<LaForge> routing code decides where to route the packet
<LaForge> packet passes hook #4 (post_routing)
<LaForge> packet hits the wire of the network

Das erklärt einiges. Wie gesagt, ich habe zunächst die Einstellungen
von einem Buch (Ziegler - Verlag Markt und Technik) einfach
kritiklos übernommen, nachdem ich iptables als masquerading aber
ohne drops mit Erfolg eingesetzt hatte. Irreführend war ja die
Tatsache, dass dhcp auch mit "gedropten" nat+mangle zunächst
einmal funktioniert. Es funkioniert sogar das automatische
Auffrischen, nur ein gezieltes Erneuern scheitert.

das interview ist auf:
http://www.kernelnewbies.org/documents/irclogs/netfilter.log

Werde ich nachlesen.

da sind dann noch mehr solcher interviews und dokumente:
http://www.kernelnewbies.org/documents/

peter

Nochmals danke an alle
Luigi