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 ...
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
This archive was generated by hypermail 2b29 : Tue Jan 23 2001 - 21:00:31 EST