Hello,
On Wed, 23 Jan 2002 kuznet@xxxxxxxxxxxxx wrote:
> > Of course, the SNAT-ing process may be needs correct routing (may be
> > a new "ROUTING" chain) and little routing code changes (I have it in some
> > my patches).
>
> BTW this is puzzle for me: how do they block redirects?
> This was another big problem with masquerading in 2.2 and in fact another
> advantage of controlling masquearding via routing, when all such things
> went right automatically.
I forgot to mention another thing: users report that there
are applications that change the tos in established state (openssh?).
This change causes ip_route_input to select different path from
the multipath route when masqueraded. I hope this does not happen
for related ICMP packets, I see that icmp_send copies the tos from
the request packets. But wait, the tos is copied from the out->in
packets while the in->out packets have their own tos that can be
different. I'm not sure whether we misroute these related ICMPs
when masqueraded (if such ICMPs really can be generated from a
masqueraded box). And again, ip_route_input's lsrc arg is a
solution for this problem. The result:
- we need a place (ROUTING chain?) where each masqueraded connection
can feed ip_route_input with the desired data (lsrc). If there is
no lsrc, then the RT_TOS(tos) arg must be always constant for the
masqueraded conn even for the related ICMP traffic because we
risk to select different path. Of course, if lsrc exists, we
can feed ip_route_input with different tos values, we don't care,
we don't risk to select path with distinct IP block that drops
the packets with other src IPs. The masqueraded connections
will behave nearly to a TCP/UDP socket in its routing usage:
they are usually bound to maddr, they can change its tos.
- without lsrc arg the multipath usage can easily fail on route
cache flush
- the usage of lsrc does not generate ICMP redirects (you will
not worry about netfilter and ICMP redirects :))
- the bad thing: the ip_route_input prototype is changed :(
Different issue: the Linux Virtual Server can use this
ROUTING hook to call ip_route_input with different args, i.e. not
always with args extracted from the iph because we can forward
packets without changing address information in it.
> Alexey
Regards
--
Julian Anastasov <ja@xxxxxx>
|