Hello,
On Tue, 22 Jan 2002 kuznet@xxxxxxxxxxxxx wrote:
> Hello!
>
> > I'm guilty, what to say more. I resurrected the route
> > masq usage in 2.4:
>
> Does resurrection make a sense??
> What are reasons to do this? iptables seem to do everything.
>
> I made this trick in 2.2 because people (particuarly, me) wanted
> masquerading to work and ipchains did not provide this facility
> masquearading to a random address.
>
> I am afraid it is not resurrection, but rather waking up a zombie.
:) I find the route masq useful in some complex setups
where many local networks exist (without NAT-ing between them),
there is NAT to other networks and where the result is a complex
list of iptables/ipchains NAT rules (ACCEPT exceptions, SNAT...).
We know, rtmasq selects source per route path while the netfilter
selects source for each connection, so may be the NAT setup will
be faster for rtmasq. Even if Netfilter is smarter when setting up
the NAT connections, the result can be difficult management of
NAT rules and the most bad thing: not sync-ed with the routing.
I can speedup the fib_rules_policy() code by not calling
inet_addr_type() for the "nat 0.0.0.0" case which is the most used
one. So, the feature should not add any performance degradation.
So, nothing new as you see, only some simplification in
the NAT rules (which are not visible for small number of networks).
So, rtmasq is a different way to be happy :) I don't have more
ideas on this topic :) May be I'm too tired to add many Netfilter
rules :) If the netfilter gurus don't find it useful, no problem :)
> > http://www.linuxvirtualserver.org/~julian/#rtmasq
>
> It is intersting in any case. I even did not know that this is possible. :-)
Yes, the good thing in Netfilter is that we can setup the
connections in many different ways and then the code will maintain them.
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).
> > May be one bug: inet_rtm_delrule does not match the
> > srcmap (RTA_GATEWAY) and by this way a wrong rule is deleted
> > when they differ only by srcmap. Is it fixable?
>
> No, I think. Actually, I planned to kill the match against everything
> but priority. But the more I delayed this change, the more
> it was cathastrophic. Well, look into ip-cref, it directly warns
> about this change in future and prescribes to give an explicit priority.
May be I have the rules with same priority, anyways :)
There are so many free priorities, so it does not matter so much.
> But I will concentrate all the will and will do it in 2.5.
>
> Alexey
Regards
--
Julian Anastasov <ja@xxxxxx>
|