|
Hi,
-A POSTROUTING -s 192.168.10.5/255.255.255.255 -o eth0:5 -j MASQUERADE
-A POSTROUTING -s 192.168.10.6/255.255.255.255 -o eth0:6 -j MASQUERADE
-A POSTROUTING -s 192.168.10.7/255.255.255.255 -o eth0:7 -j MASQUERADE
>
I don't know that iptables works with ip aliases. I don't think that
ipchains even did
It kind of works by stripping away the stuff after the ':'. There are different
versions of this floating around including a patch of mine. While it doesn't
make sense to specify a label when a device entry is asked for, I can imagine
that people like to get the label as an output to 'ip[chains|tables] -n -L'.
I've made a patch for ipchains to support labels (aliases) as an input but it
will only strip away the rest of the label because the matching is still on the
physically underlying interface, in the OP's case: eth0.
For iptables, I found out that due to massive inconsistency in the iptables
userspace tool in the parser there are combinations of table/chain/target where
a label is happily accepted and there are combinations where it isn't.
Once I've done a complete analysis on the aberrant behaviour of iptables with
complex <table/chain/target/match> tuples I will forward my findings to Harald
as a bug report.
Regards,
Roberto Nibali, ratz
--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
|
