I could not come up with a good solution. It is not possible to avoid
double lookup in the set if the elements may have (say hash:ip,port type
of set) the forms:
ipaddr,tcp:port
ipaddr,udp:port
ipadd,tcpudp:port
I was thinking that you may interpret either the absence of the protocol
specification ('tcp', 'udp' and 'tcpudp' in your examples above) or the
word 'all' (even '*' though I don't know if that's possible) to mean
that no protocol match is necessary.
But if the double-lookup is required, then better add all tcp and udp port
variants and go with a single-lookup.
I am not sure I understand you.
Or if you have uniform ports for all elements, you can use two set
matches:
ipset create hash:ip ipaddrs
ipset create bitmap:port ports
... -m set --match-set ipaddrs dst -m set --match-set ports dst ...
There is a problem with this - the 'bond' which exists with (the
imaginary and working) hash:ip,all,port (i.e. the implicit link between
the element's ip address/subnet and the port or port range) is not
there if two separate sets are used!
In order to create this 'bond' I have to use not one, but two separate
sets (i.e. vpn_hosts/vpn_ports) and even then I cannot control this fully.
One very simple example: if I have a vpn host group which is on the
10.1.1.0/24 subnet and operates within the 1194 (tcp/udp) port range and
then have another vpn host group 10.1.2.0/24 which operates on a
different port range - 80,443 (tcp and udp).
If I follow your example above I have to define *four* sets to
accommodate the double matches, because if I put all the vpn ports into
one ipset group (say vpn-ports) which contains ports 1194,80 and 443 and
then use a similar ipset for the vpn hosts (say vpn-hosts) containing
10.1.1.0/24 and 10.1.2.0/24 as its members and then do a double match
"-m set --match-set vpn-hosts dst -m set --match-set vpn-ports dst" that
would mean packets destined to 10.1.1.0/24 on ports 80,443 (tcp/udp) and
10.1.2.0/24:1194 (tcp,udp) will be allowed which is not what I want.
If I want to separate this fully and make it work as it should, I have
to define *four* sets (vpn-hosts1->10.1.1.0/24, vpn-ports1->1194, then
vpn-hosts2->10.1.2.0/24,vpn-ports2->80,443), which makes the whole job
rather cumbersome. I currently have this problem when I employ a similar
approach with the existing 4.x version of ipset.
If ipset 5.x can disregard the protocol match I will have to define a
single set and place just 3 members in it: 10.1.1.0/24,all,1194;
10.1.2.0/24,all,80 and 10.1.2.0/24,all,443
--
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
