Hallo und guten Morgen ihr zwei!
Hm.... der Teil belegt jetzt wie die Sache laufen sollte, nur verstehe ich genausowenig wie eine eingehende Anfrage eintreffen kann, wenn im prerouting nur eine Drop-Policy steht. Aber egal, ich muß mich voraussichtlich diese Woche eh noch tiefer mit ein paar Sachen aus dem Bereich beschäftigen. Wenn es euch interessiert werde ich ein paar Tests machen.
Grüße,
Günther
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@energis.it Web: http://www.energis.it
Am Dienstag, 27. Mai 2003 02:06 schrieb Peter Warasin: 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 :) <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
http://www.lugbz.org/mailman/listinfo/lugbz-list LUGBZ is pcn.it-powered
_______________________________________________ http://www.lugbz.org/mailman/listinfo/lugbz-list LUGBZ is pcn.it-powered
Am Montag, 26. Mai 2003 09:03 schrieb guenther.mair@energis.it: Hallo
Hallo und guten Morgen ihr zwei!
Hm.... der Teil belegt jetzt wie die Sache laufen sollte, nur verstehe ich genausowenig wie eine eingehende Anfrage eintreffen kann, wenn im prerouting nur eine Drop-Policy steht. Aber egal, ich muß mich voraussichtlich diese Woche eh noch tiefer mit ein paar Sachen aus dem Bereich beschäftigen. Wenn es euch interessiert werde ich ein paar Tests machen.
mich interessiert es bestimmt. Grüße Luigi
Grüße,
Günther
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@energis.it Web: http://www.energis.it
Am Dienstag, 27. Mai 2003 02:06 schrieb Peter Warasin: 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 :) <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
http://www.lugbz.org/mailman/listinfo/lugbz-list LUGBZ is pcn.it-powered
http://www.lugbz.org/mailman/listinfo/lugbz-list LUGBZ is pcn.it-powered
http://www.lugbz.org/mailman/listinfo/lugbz-list LUGBZ is pcn.it-powered