On Sat, Jul 10, 2010 at 19:00, Mart Frauenlob <mart.frauen...@chello.at> wrote:
> This picture shows the netfilter traffic flow:
> http://jengelh.medozas.de/images/nf-packet-flow.png
>
> Source address selection is done before the OUTPUT path.
> Locally generated packets NEVER hit the PREROUTING chain in mangle or nat
> table.
> There is a routing decision after the mangle table OUTPUT chain.
> But you cannot do address translation there (like in nat OUTPUT).
> What you can do, is MARK packets in the mangle table, and refer to this mark
> with iproute2 (ip rule add fwmark 0x1 lookup table custom_table) - this is
> called "policy based routing".
>
>
> So from looking at the picture and from the theory I know, theoretically
> something like this could work:
>
> echo "101 custom_table" >> /etc/iproute2/rt_tables
>
> fill the table with appropriate routes:
> ip route add table custom_table ...
> ...
>
> mark in mangle table:
> iptables -t mangle -A OUTPUT -d 127.0.0.1 -p tcp --dport 5432 -j MARK
> --set-mark 0x1
>
> dnat in nat table:
> iptables -t nat -A OUTPUT -m mark --mark 0x1 -j DNAT --to-destination
> 192.168.1.113
>
> snat in nat table:
> iptables -t nat -A POSTROUTING -m mark --mark 0x1 -j SNAT --to-source
> 192.168.1.1?
>
> add iproute rule:
> ip rule add fwmark 0x1 lookup custom_table
>
>
> I've done all this for testing and I did not succeed.
> I also did:
> echo 0 >/proc/sys/net/ipv4/conf/all/rp_filter
> not sure if that interacts.
> I then put a trace rule:
> iptables -t raw -A OUTPUT -d 127.0.0.1 -p tcp --dport 5432 -j TRACE
>
> The resulting log always ended in the nat table's OUTPUT chain.
> I don't know why acutally, from the picture (which is from a developer) it
> should hit nat POSTROUTING.
> I'm telling you this, so you could eventually try and maybe you have more
> luck than me, or maybe the information is otherwise useful.
> However maybe it's not possible, I can't tell for sure.
> I would have done some ssh tunneling myself in the first place.
> But I know there are people at the netfilter mailing list, who do know for
> sure. It's in general the best place to ask netfilter related questions.
>
> Best regards
>
> Mart
Thanks Mart,
your experiment will not be lost.
At the moment I have not a lot of time to spend extending your work,
but it is a good starting point for further enhancement.
As you are suggesting, I'll integrate it with the infos coming from the
netfilter mailing list and #Netfilter irc channel.
At the moment, the good news is that, together with the ssh,
netcat, and socat animals, we have a new friend:
xinetd
service postgresql
{
socket_type = stream
wait = no
user = root
redirect = 192.168.1.113 5432
bind = 127.0.0.1
}
Thanks again for the time spent answering me.
Daniele
p.s.:
The xinetd tip comes from SuperJediWombat! of linuxquestions.org.
http://www.linuxquestions.org/questions/linux-networking-3/iptables-redirect-127-0-0-1-to-192-168-1-113-a-818817/
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/aanlktila28gqhmpb75bm18kci-h7ufng0er53lg9j...@mail.gmail.com
