netdev - Re: [patch v2 03/12] [PATCH 03/12] IPVS: compact ip_vs_sched

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.1010050010080.1856@ja.ssi.bg>
Date:	Tue, 5 Oct 2010 01:36:53 +0300 (EEST)
From:	Julian Anastasov <ja@....bg>
To:	Simon Horman <horms@...ge.net.au>
cc:	lvs-devel@...r.kernel.org, netdev@...r.kernel.org,
	netfilter@...r.kernel.org, netfilter-devel@...r.kernel.org,
	Jan Engelhardt <jengelh@...ozas.de>,
	Stephen Hemminger <shemminger@...tta.com>,
	Wensong Zhang <wensong@...ux-vs.org>,
	Patrick McHardy <kaber@...sh.net>
Subject: Re: [patch v2 03/12] [PATCH 03/12] IPVS: compact
 ip_vs_sched_persist()


 	Hello,

On Sat, 2 Oct 2010, Simon Horman wrote:

>> 	I'm still wondering, may be it needs separate patch
>> but we do not support NAT to different dest->port in the
>> case for fwmark. May be the above logic can be changed to
>> support it. By this way web to different VIPs and VPORTs
>> in a single virtual service (fwmark) can use single NAT
>> real server for name-based virtual hosting. But such change
>> can create compatibility problems for setups that used
>> different vports for the fwmark service and still expect
>> it in that way (vport to same dport).
>
> Hi Julian,
>
> I think that this sounds line a new flavour of fwmark virtual services to me.
> Perhaps yet another flag is in order?
>
> To be clear, what you have in mind is essentially to nat *:* (as matched by
> a fwmark) to x:y, where as at this time *:y may be natted to x:y.

 	Yes, the difference is here, persistent services with fwmark 
ignore dest->port while non-persistent services with fwmark prefer
dest->port:

ip_vs_sched_persist:
         dport = ports[1];
         if (dport == svc->port && dest->port)
                 dport = dest->port;
 	- before the PE changes even dest->port=0 was selected
 	for non-fwmark

ip_vs_schedule:
 	dport set as: dest->port ? dest->port : pptr[1]

 	It is inconsistent. If we add new option for dest
it should have 3 states:

0: default (current, compatible)
1: prefer real server port
2: keep dport in packet

 	But the same can be done with rport or that was the
goal before:

- rport=0 (zero port) - keep dport from packet
- rport>0 - use this real server port

 	It works perfectly for ip_vs_schedule but not for
ip_vs_sched_persist, rport>0 is ignored for persistent
fwmark and this is wrong for NAT. Persistence should just
select dest but now it changes the rport semantic. The
right thing is ip_vs_sched_persist to work as ip_vs_schedule
but it can break some setups with persistence and fwmark.

Regards

--
Julian Anastasov <ja@....bg>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html