Author: adrian.chadd
Date: Fri Jun 26 00:00:20 2009
New Revision: 14102
Modified:
wiki/LuscaArchitectureNetworkTransparentInterception.wiki
Log:
Edited wiki page through web user interface.
Modified: wiki/LuscaArchitectureNetworkTransparentInterception.wiki
==============================================================================
--- wiki/LuscaArchitectureNetworkTransparentInterception.wiki (original)
+++ wiki/LuscaArchitectureNetworkTransparentInterception.wiki Fri Jun 26
00:00:20 2009
@@ -4,6 +4,8 @@
Lusca supports client-side and server-side IPv4 address spoofing for a
variety of platforms.
+Please note that this documentation is intended as an overview. The
authoritative source is the code and the code documentation.
+
= Background =
Squid has supported client-side interception for a number of years. The
support includes a variety of possible code paths for each operating system
and firewall type (IPFilter, IPFW, Netfilter, PF.) Recently, support for
the Balabit TPROXY2 and TPROXY4 interception frameworks allow Squid to
intercept both client and server facing traffic, presenting a (mostly!)
seamless transparency to both sides of the connection.
@@ -28,6 +30,16 @@
Further changes to the Lusca codebase are aimed at creating a clear API
for defining inbound and outbound transparently intercepted connections.
+== Accepting new connections ==
+
+From a socket level, the interception code from Squid-2 doesn't really
treat intercepted connections any differently. A normal IPv4 socket is
created, bind(), listen(), and accept() happen just like a non-interception
method.
+
+The majority of the differences lie in how the connection is treated. An
intercepted connection requires Lusca/Squid to treat the request as if it
were the origin server. This has subtle changes in the request URI and Host
header requirements.
+
+There are specific hacks which try to determine the original destination
address. This is used when no specific Host: header is given.
+
+Linux TPROXY4 changes this slightly. Since TPROXY4 specific rules are
involved in the interception, a specific socket option is required
(IP_TRANSPARENT) before the bind() and listen() syscalls are called.
+
= Network topology implications =
Full transparency requires the proxy server to see both sides of the
traffic flow. It will then redirect relevant packets making up the
intercepted client and server connections through the correct sockets.
@@ -38,13 +50,9 @@
== Accepting transparently intercepted connections from clients ==
-From a socket level, the interception code from Squid-2 doesn't really
treat intercepted connections any differently. A normal IPv4 socket is
created, bind(), listen(), and accept() happen just like a non-interception
method.
-
-The majority of the differences lie in how the connection is treated. An
intercepted connection requires Lusca/Squid to treat the request as if it
were the origin server. This has subtle changes in the request URI and Host
header requirements.
-
-There are specific hacks which try to determine the original destination
address. This is used when no specific Host: header is given.
-
-Linux TPROXY4 changes this slightly. Since TPROXY4 specific rules are
involved in the interception, a specific socket option is required
(IP_TRANSPARENT) before the bind() and listen() syscalls are called.
+ * Create a socket using comm_open() with the relevant comm flags. If the
connection needs to handle client-spoofed requests, set COMM_TPROXY_LCL. If
the connection is just doing normal server address spoofing and no client
address spoofing, no special flag is (currently) needed. (Note - this will
change in the future for the sake of completeness.)
+ * Call comm_listen()
+ * Setup an FD handler using commSetSelect() to handle incoming requests
== Determining the original destination server IP address ==
@@ -55,7 +63,13 @@
* PF - an ioctl is performed on an open filedescriptor to /dev/pf -
DIOCNATLOOK
* IPFilter - simiarly to PF, an ioctl is performed on an open
filedescriptor to an ipfilter device.
+This is all done in client_side.c:clientNatLookup() - it is not yet
available as a generalised API for determining the original destination.
+
== Using a non-local IP address on an outbound connection ==
+
+ * Create a socket using comm_open() with the comm flag COMM_TPROXY_REM
set.
+ * COMM_TPROXY_REM allows the local address specified in comm_open() to
be non-local.
+ * Complete the connection as normal.
= Implementation notes =
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"lusca-commit" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/lusca-commit?hl=en
-~----------~----~----~----~------~----~------~--~---
