Darryl Miles a écrit : > > >As no solution appeared, I try again, here is my config (figure > >clarified by Darryl Miles) > > > > 10.67.28.0/24 > > -----------+----------------------------------+----------- > > eth1 | 10.67.28.2 eth1 | 10.67.28.1 > > +-----+-----+ +-----+------+ > > | FIREWALL | | HOST | > > | | | | > > +-----+-----+ +-----+------+ > > eth0 | 10.67.27.2 eth0 | 10.67.27.1 > > -----------+----------------------------------+----------- > > 10.67.27.0/24 > > > > > >The question: > >From the host, how to force a packet destined to 10.67.27.1 to go > >through the firewall since > > > >route add -host 10.67.27.1 gw 10.67.27.2 dev eth0 > > > >is not enough ? > > Ah, I had presumed the IP you were trying to route to is on FIREWALL and > not on HOST, by using the non-obvious path/interface selection to get > there. > > What you want is simply not normal, since what you are asking is the > kernel treat the packet as non-local when it sends it out on eth1 to > FIREWALL and then treat it as local when it arrives back in again at > eth0 on HOST. It is really make up your up mind time, is the address to > be accepted locally by host or not? That's the point, I would like asymetrical routing between emission and reception. As far as I understand routing, such a criteria cannot be taken into account, ie packets are all processed the same way, and are routed according to routing table, no matter originating inteface/local process ... true ? Maybe packet filtering (iptables) could be helpful: From an IP point of view, I configure my packets as not local (on host) to have them go through the firewall, and in iptables (on host), I redirect these packets, only when incomming, to a local process. Is this likely to work ? > I don't believe any amount of configuration using stocks tools or kernel > will achieve what you want, unless you can move the 'local' table from > rule '0' to rule '1' and insert your own table before it. However I > suspect table number 0, the local table is hardcoded to be 0 in the > kernel for the very good reasons above that local processing is done > first BEFORE a forwarding decision is made. > > I can however offer as possible solution: > > 10.67.28.0/24 > -----------+----------------------------------+----------- > eth1 | 10.67.28.2 eth1 | 10.67.28.1 > +-----+-----+ <<<<<<< +-----+------+ > | | v ^ | | > | FIREWALL | v | HOST +--- SLIP link > --+ 10.67.27.3 > | | v ^>>> | | > +-----+-----+ >>>>>>> +-----+------+ > eth0 | 10.67.27.2 eth0 | 10.67.27.1 > -----------+----------------------------------+----------- > 10.67.27.0/24 > > Configure HOST with a policy route or two. > > The IP address of 10.67.27.3 would be setup as a SLIP link through a > pseudo-tty device, loopbacked to a process on the HOST machine. This > should only be any good as an interface which can sink packets to, this > maybe easier to achieve by using policy routing and bitbucket routing > entries to an arbitary address (which isn't considered local to either > HOST or FIREWALL). > > So it depends if you want the destination test address to act as a > bitbucket or have a real application on the end of it. I would like a real application > Why not use another machine in this excercise? Use tcpdump on the > return interface of FIREWALL, from HOST to monitor what is happening. > Maybe this is a dumb comment from me, like if you could you would have > by now :) that's what I'm doing :), but if I could spare a box or two ... - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org
