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@energis.it Web: http://www.energis.it
Peter Warasin <Peter.Warasin@darkr An: lugbz-list@lugbz.org ealms.org> Kopie: guenther.mair@energis.it Gesendet von: Thema: Re: Antwort: [Lugbz-list] iptables lugbz-list-admin@lug bz.org
25.05.2003 13:06 Bitte antworten an lugbz-list
hallo
On Fri, 2003-05-23 at 21:50, luigi wrote:
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#...
_______________________________________________ http://www.lugbz.org/mailman/listinfo/lugbz-list LUGBZ is pcn.it-powered
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 :) <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
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
-
guenther.mair＠energis.it -
luigi -
Peter Warasin