Scheidler, Balázs wrote, On 01/18/2015 07:49 AM:
> The problem is that the synack in response to the syn goes out to the
> internet towards the faked IP address, and not back to the loopback
> interface.
>
> The problem is that the same return traffic is used by the client side of
> the proxy as well.
>
> So if you have a means to differentiate the two (match on the process
> somehow for example), then use that to mark server side packets, and then
> have routing tables that enforfes these packets to be delivered locally
> would work.
Yes, that makes sense and at first look it seems to be easy to do.
I'll have to experiment, but if you, or anybody else, have already
done this successfully I would be happy to see your solution.
But I think a more general and user-friendly solution would be
if that fix could be implemented into the kernel where the routing decision is
made, isn't it?
Thx
Uenal
> On Jan 18, 2015 3:23 AM, "U.Mutlu" <for-forums(a)mutluit.com> wrote:
>
>> Hi John,
>>
>> John Lauro wrote, On 01/18/2015 01:59 AM:
>>> I have done used it with single interface on the box running tproxy and
>>> the server on the same subnet also with a single interface. (Technically
>>> they have extra interfaces with policy based routing for handling
>> outgoing
>>> connections differently, but probably not strictly required unless you
>> are
>>> doing ANYCAST).
>>
>> yes, my current working solution is similar, but now I need to run
>> both the server app and the proxy app on the same box.
>>
>>> I would think that at a minimum, if you run on the same box and want to
>>> reuse the client's ip on the application, you will have to use a
>> secondary
>>> IP on the same interface, or possibly a loopback interface. You might
>>> have to setup policy based routing from that secondary IP so it stays
>>> local, just a guess. Is it ok to bind the app to listen on 127.0.0.1
>>> or some other secondary IP?
>>
>> Have you in practice used such a single-box solution?
>> If yes, I would very much appreciate if you could post the relevant steps
>> (iptables, ip route etc.).
>>
>> As said. I already tried this by binding the server app to a secondary IP,
>> but I guess my other stuff (iptables, rules, routes) wasn't right.
>>
>>> Easier would be if you could loose the client IP info on the app (track
>>> or tag it with the proxy) and just recreate a new session... but I
>> assume
>>> that is not an option...
>>
>> Hmm. I try to avoid this in favour of keeping the tproxying independent
>> of the capabilities of the server app(s).
>>
>> Thx
>> Uenal
>>
>>
>>> ----- Original Message -----
>>>> From: "U.Mutlu" <for-forums(a)mutluit.com>
>>>> To: tproxy(a)lists.balabit.hu
>>>> Sent: Saturday, January 17, 2015 6:56:57 PM
>>>> Subject: [tproxy] proxy app and server app on the same host
>>>>
>>>> Hello,
>>>>
>>>> TPROXY works fine if the server application is on a different host,
>>>> and if that host has the proxy host defined as its gateway.
>>>>
>>>> I have this special tproxy requirement:
>>>> A transparent proxy program needs to sit between client and server
>>>> program,
>>>> ie. like a MITM, and both (proxy pgm and server pgm) must be on the
>>>> same host.
>>>> The host has only one physical interface (eth0).
>>>>
>>>> So, I have to move the server app to the proxy host.
>>>> But then TPROXYing no more functions.
>>>> I'm sure it's a routing problem, but I couldn't find a solution yet.
>>>> I know some advanced routing (policy routing), ie. using different
>>>> routine
>>>> tables and assigning rules for them etc., but if everything is on the
>>>> same
>>>> host then somewhere it hangs; the SYN-ACK of the server app doesn't
>>>> receive
>>>> the proxy pgm, it seems to go out to the internet.
>>>>
>>>> I also tried with alias IPs, virtual subnets, and also with tap
>>>> devices,
>>>> unfortunately the results so far are negative :-(
>>>>
>>>> The author of haproxy writes at their web site
>>>>
>> http://blog.loadbalancer.org/configure-haproxy-with-tproxy-kernel-for-full-…
>>>> "We also need to ensure that we have the correct architecture for the
>>>> TPROXY
>>>> trick to work. Using the normal HAProxy you can have real servers
>>>> anywhere on
>>>> the internet because the source address always points back at the
>>>> HAProxy
>>>> units IP address. However if the clients source IP address is going
>>>> to be used
>>>> then the HAProxy server MUST BE IN THE PATH of the return traffic.
>>>> The easiest way to do this is to put the backend servers in a
>>>> different subnet
>>>> to the front end clients and make sure that the default gateway
>>>> points back at
>>>> the HAProxy load balancer.
>>>> NB. With clever routing this should be possible on the same subnet
>>>> but I
>>>> haven’t tried that yet!
>>>> "
>>>>
>>>> So, I'm looking for the above said "clever routing" solution.
>>>>
>>>> Could someone help me please?
>>>>
>>>> My environment: recent Linux kernel (3.16), Debian 8, x86_64
>>>>
>>>> Thx
>>>> U.Mutlu
Hello,
TPROXY works fine if the server application is on a different host,
and if that host has the proxy host defined as its gateway.
I have this special tproxy requirement:
A transparent proxy program needs to sit between client and server program,
ie. like a MITM, and both (proxy pgm and server pgm) must be on the same host.
The host has only one physical interface (eth0).
So, I have to move the server app to the proxy host.
But then TPROXYing no more functions.
I'm sure it's a routing problem, but I couldn't find a solution yet.
I know some advanced routing (policy routing), ie. using different routine
tables and assigning rules for them etc., but if everything is on the same
host then somewhere it hangs; the SYN-ACK of the server app doesn't receive
the proxy pgm, it seems to go out to the internet.
I also tried with alias IPs, virtual subnets, and also with tap devices,
unfortunately the results so far are negative :-(
The author of haproxy writes at their web site
http://blog.loadbalancer.org/configure-haproxy-with-tproxy-kernel-for-full-…
"We also need to ensure that we have the correct architecture for the TPROXY
trick to work. Using the normal HAProxy you can have real servers anywhere on
the internet because the source address always points back at the HAProxy
units IP address. However if the clients source IP address is going to be used
then the HAProxy server MUST BE IN THE PATH of the return traffic.
The easiest way to do this is to put the backend servers in a different subnet
to the front end clients and make sure that the default gateway points back at
the HAProxy load balancer.
NB. With clever routing this should be possible on the same subnet but I
haven’t tried that yet!
"
So, I'm looking for the above said "clever routing" solution.
Could someone help me please?
My environment: recent Linux kernel (3.16), Debian 8, x86_64
Thx
U.Mutlu