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