As for ipportiphash and ipportnethash - there were recently included in
the distribution due to another bug I found when compiling xtables (even
though ipportiphash and ipportnethash were compiled the .ko files were
never included in the final release making it impossible to use these
two construct types).
A couple of questions and ideas for future releases:
1. Normally I used to get ipset as part of the xtables source. Is that still
the case or do I have to download the ipset source and compile it separately
to get the latest changes you made?
It's absolutely up to you: currently ipset can be installed alone, or as a
part of xtables-addons. Jan updates xtables-addons quite reqularly.
I just taken the latest git from xtables-addons and it is not there.
2. Related to that question - I used to get the xtables .src.rpm from which to
compile the code and make an installation rpm. I don't seem to be able to do
that any longer as all fedora repos are too slow to update the latest changes.
Do you have a link from which I could get the latest changes in ipset/xtables
in src.rpm which allows me to build an installation rpm. The reason I am
asking this is because I am building an update images on all my machines
(using kickstart) and need the installation rpms with the latest changes you
made. Compiling this from source won't be possible as there is now way I could
install this as part of the image-building process.
No, I'm not aware of the source rpm for ipset. That's bad if there's one
out there without refreshed.
This is a major headache for me for 2 reasons:
1. I use 'rpmbuild' to compile from source as it allows me to build rpms
for different architectures (I compile on x86_64 for i686 with 'rpmbuild
--target=xxx'). If I use 'ordinary' make there is no way (at least I
don't know of any) I could compile for different architecture.
2. rpmbuild also allow me to pack the necessary binaries (executables &
modules/.ko files) for the target architecture to be transferred to the
target machine - conveniently in rpm which could be installed (together
with the necessary dependencies) as part of the target image building
process.
Even if I solve problem No 2 (i.e. by tar-ing the necessary modules and
executables) I can't see a way to get past compiling for a different
architecture (and resolve all the dependencies)! Any ideas?
On a side note, I just managed to built v4.4. in the last hour or so for
x86_64 (haven't tested it yet) and had to readjust the prefix & lib
directories in the Makefile (I use prefix=/ and libdir=/lib64) and
installed the new version, but I can't do anything for my other machines
(which are mostly i686-based and their image is built using kickstart).
Would it be possible to include a new construct - IP,port,IP,port (without IP
address restriction) - and how difficult is this to implement?
It's not difficult, but I see little value in such a type. The client
source port (except for a few protocols in some cases) is random, so how
could it be useful to mach for that? Or do you know a case where it can
still be useful?
I can give you of at least 2 uses based on my experience:
1. voip - normally I can restrict the range of source ports and ip
address when a voip connection is initialed (usually ports 8000-8050 and
I have to also define the right ip address to point to the outside
network), but the only way I can do this at present is if I base this on
UID in iptables (i.e. the id of the process this is run under) - I
cannot use sets at all because I do not have the appropriate construct.
If I had "IP,port,IP,port (and protocol!)" as a construct to work with I
can just built the sets (as I use 4-5 different servers outside the
network and they work on different ports too) and that would be it!
2. VPN - for the same reason: to increase security I normally bind the
source port to a particular range and then if I had a "IP,port,IP,port
(and protocol!)" construct to work with I will not be using UID in
iptables to match, but will use this construct directly without any
further need to do anything!
Similar question - would it be possible to include protocol (either by name or
its number) as part of all available constructs for matching? The reason for
this is that, as it stands, in order for me to match, say, "IP,port" hosts
form my personal VPN I need to use two separate sets - one for UDP and one for
TCP and I also to create two separate statements for iptables (one for tcp and
one for udp), which is a bit of a waste and not very easy to administer. It
would be nice if I could use "IP,protocol", "port,protocol",
"IP,port,protocol", "IP,port,IP,protocol", "IP,port,IP/cidr,protocol" and so
forth.
The next branch includes exactly that, i.e. the possibility to specify
proto:port for the ipport, ipportip and ipportnet types. And IPv6 support
too.
That's brilliant news! I take it you will be introducing protocol
support for all the constructs, is that right? How long would it take
before you release this?
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
