lkml.org 
[lkml]   [2001]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Transparent proxy support in 2.4 - revisited
On Mon, Sep 03, 2001, Andrey Savochkin wrote about "Re: Transparent proxy support in 2.4 - revisited":
> > Unfortunately, that's not enough. When the return SYN-ACK packet carrying a
> > non-local destination address is received (in practice, the transparent
> > proxy machine is acting as a default gateway to the other machine), this
> > packet is either ignored or forwarded out (depending on ip_forward), but is
> > never accepted as a local packet and transfered to the appropriate socket
> > as it should.
>
> Right.
> In 2.2 kernel you also needed to configure which incoming packets you want to
> handle locally.

If I remember correctly, no such configuration was needed if the
CONFIG_IP_TRANSPARENT_PROXY compilation flag was enabled. As I understand from
a cursory examination of the 2.2 source, Whenever packets were received and
were not meant for the local address, a check would be made if they meant for
one of the transparent-proxied connections (i.e., connections whose local
endpoint isn't local).

This is the kind of thing I need in Linux 2.4 too.
I'm still puzzled by the fact that this support simply disappeared between
2.2 and 2.4, and nobody seems to know why (or people who know why don't
reply).

> If you want to handle locally all packets destined to a specific IP address,
> just add local route.
> If you want some complex matching rules, check iptables, there was something
> about "redirects" there.

Remember that the reverse proxy machine, the one faking connections with an
adjacent server (as if they are coming from the actual clients) also serves
as the the gateway for that server and needs to forward packets for it.
So I can't redirect *all* packets to local sockets, yet I also can't pick
specific IP addresses to redirect (unless I write some sort of hack to
modify the iptables tables dynamically as new non-local bind()s happen).
Not to mention that the standard redirect, which also rewrites the destination
address on the packet (if I remember correctly), isn't quite what I need when
I already have a socket bound to a non-local address.


> You seemed to start to solve your problems from the wrong end.
> First of all, decide how to handle incoming packets.
> Then consider outgoing.

You're right. But I started at the easier end :)



--
Nadav Har'El | Monday, Sep 3 2001, 15 Elul 5761
nyh@math.technion.ac.il |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |I'm a peripheral visionary: I see into
http://nadav.harel.org.il |the future, but mostly off to the sides.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:17    [W:1.987 / U:24.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site