On 11/13/2012 10:25 AM, Jozsef Kadlecsik wrote:
On Tue, 13 Nov 2012, Stephen Clark wrote:
On 11/12/2012 06:30 PM, Pablo Neira Ayuso wrote:
On Mon, Nov 12, 2012 at 08:34:26PM +0100, Jozsef Kadlecsik wrote:
On Mon, 12 Nov 2012, Chris Wilson wrote:
I propose that:
* when the packet matches an existing conntrack rule, and
* is sent out of an interface that does not list the packet's new
(SNAT-to)
source address as one of its IP addresses (i.e. if this were a new
connection, MASQUERADE would not choose this source address), and
* the --update-source-address flag is set on the MASQUERADE target
then update the source address on the conntrack rule to the new one.
That's the same thing that would happen if we deleted the conntrack
entry
first: MASQUERADE would choose a new source address and save it in the
new
conntrack entry.
What do you think about this?
- add route change notification event to the net core
- add --update-source-address flag to the MASQUERADE target
- add a call for such events to the MASQUERADE target, when
the flag is enabled
The called function then can scan the conntrack table and for every entry
which has got the update-source-address flag, can check whether the source
IP address should be changed. Those entries are then deleted.
It seems to me this can be implemented this from user-space. It would
require a new working mode for conntrackd that would:
1) subscribe to route events via rtnl and libmnl.
2) get new interface address for some monitored address, also via rtnl.
3) iterate over the table and remove those entries with outdated IP
address.
All the infrastructure is ready, and it would not require any kernel
upgrade. What do you think about this approach?
A similar problem exists in the following scenario:
You have two upstream isp that you are doing load balancing by having multiple
default routes:
default
nexthop via 66.xxx.xxx.xxx dev eth1 weight 1
nexthop via 205.xxx.xxx.xxx dev eth2 weight 1
On one of the external interface you have a DNAT to
an internal server on a private address. The DNAT makes
a conntrack entry that is going to in effect do a SNAT on reponses
from the internal server back out to the internet, but the load balancing
decision on routing happens before this implicit SNAT so you have packets
trying to go out an interface where the source address does not fall in the
subnet of that interface.
In my opinion this is a broken network design. The DNAT should not depend
on the external interface, problem solved.
Hmmm... what does this mean ^^^ ?
Say you have the follwoing:
eth1 with ips 66.xxx.xxx.1 and 66.xxx.xxx.2
eth2 with ip 205.xxx.xxx.xxx
eth0 with ip 10.0.1.254/24
with a server at 10.0.1.253.
iptables -A PREROUTING -i eth1 -d 66.xxx.xxx.2 -j DNAT --to-destination 10.0.1.253
How else would you access an internal server at
a private address without using a DNAT from an external public ip? Is there some
other way to do this that I am not aware of?
Why is routing decision done before the SNAT?
Because that is the natural place: this way OUTPUT and FORWARD can be
separated and we can use the original source IP addresses in the rules.
<snip>
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
