Date: Fri, 31 Jan 1997 08:55:35 +1100 (EST) From: "Daniel O'Callaghan" <danny@panda.hilink.com.au> To: Eivind Eklund <eivind@dimaga.com> Cc: Warner Losh <imp@village.org>, hackers@FreeBSD.ORG Subject: Transparent proxies (was Re: ipdivert & masqd) Message-ID: <Pine.BSF.3.91.970131084015.263G-100000@panda.hilink.com.au> In-Reply-To: <3.0.32.19970130190212.00b22780@dimaga.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 30 Jan 1997, Eivind Eklund wrote: > At 08:04 AM 1/30/97 -0700, you wrote: > I'm thinking about doing transparent proxying for the protocols, but I want > to see how well the packet-patching version run first. As it is, it is > (hopefully) right in 99% of the cases, and it scales well. If I get > reports of real-life problems I'll make it a priority to make proxies, but > not before. Here's a problem which requires transparent proxies for a data stream, not packet-patching: Transparent capture of all HTTP requests on port 80 and diversion to a www-proxy server. e.g. Client Sends "NAT" WWW-Proxy receives 10.2.3.4 10.2.3.1 10.2.3.55 10.2.3.4-> 5.6.7.8:80 ================> 10.2.3.1->10.2.3.55 GET / HTTP/1.0 GET http://5.6.7.8:80/ HTTP/1.0 Darren Reed's ipfilter does this with the 'redirect' keyword and some trickery in the receiving process. The example given is for the ftwk's ftp-gw program (from ftp.tis.com). The userland process finds its true destination by calling an IOCTL for the kernel NAT code. regards, Danny
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.970131084015.263G-100000>