really transparent proxy

[Henrik Nordstrom]

You would need to extend the inet_opt or tcp_opt structure with the 
"custom source address", and implement a new SNAT like target that 
uses this piece of information. Would be set by another setsockopt() 
call.

Entirely doable, and not violating too many layers..  (not more than 
the owner match anyway, actually considerably less). Not sure if one 
even needs to consider setsockopt() security implications either, as 
the option does not really do anything unless it is also being used 
in iptables, where there are other security checks available if one 
needs them (primarily the owner match)

Why didn't I think of this approach the last time we discussed 
transparent proxying here on the list.. probably because we also 
discussed UDP where the playfield is slightly different..

You may also need to get NAT of local connections fixed (not sure if 
this is fixed in the newnat code, havent tested it yet). Have posted 
a small patch fixing most of the issues here a couple of times, but 
haven't received much feedback from the core team.

Regards
Henrik Nordström


On Friday 01 February 2002 14.39, Christoph Dworzak wrote:
> Hi
>
> I'd like to make a transparent Proxy, but not only
> transparent to the client, but also transparent to
> the server. That would be like REDIRECT, but initiated
> from the Proxy (rewriting the source-addr on outgoing
> connection from the proxy to the server).
>
> The normal thing is (e.g. Squid):
>
> # iptables -t nat -A PREROUTING -p tcp --dport <serverport> -j
> REDIRECT --to-port <proxyport>
>
> and then in the program:
> --code-start--
> proxysock = socket(stream)
> bind(proxysock, <proxyport>)
> listen(proxysock)
> clientsock=accept(proxysock)
> clientaddr=getpeername(clientsock)
> getsockopt(clientsock, SOL_IP, SO_ORIGINAL_DST, serveraddr)
> talk_to_client_trough_clientsock
> --code-end---
>
> What is missing now is the communication with the server
> I imagine something like this:
>
> # iptables -t nat -A OUTPUT -p tcp --dport <serverport> -j REDIRECT
> --reverse
>
> --code-start--
> serversock = socket(stream)
> setsockopt(serversock, SOL_IP, SO_ORIGINAL_DST, clientaddr)
> connect(serversock, serveraddr)
> talk_to_server_trough_serversock
> --code-end---
>
> this should rewrite my local ip/port with the clients ip/port in
> the OUTPUT-chain and then rewrite answers from the server in the
> PREROUTING- chain.
>
> The SO_ORIGINAL_DST in the setsockopt could be confusing, because
> looking from the proxy it is really the original source, but
> thinking of it as reverse DNAT, it is the original destination...
>
> Is this already possible? I think not, but almost everything is
> there. We just need to store the clientaddr in setsockopt somewhere
> associated with the server-socket and then at connect-time
> create a nat/conntrack-entry. From then on it is exactly the same
> as redirect.
>
> I have two problems with implementing this:
> -I don't know where to store the clientaddr in setsockopt (there is
> no nat/conntrack tulple yet. Before connect, the serversocket
> hasn't decided yet which ip/port it gets).
>
> -Even after reading code for several days, I still don't understand
> it :)
>
> Could somebody help me with this?
>
> bye
>  dworz