[tproxy] Squid with tproxy extra brief FAQ - take 2

[Balazs Scheidler]

Do you mind if we post this information on the webpage of tproxy?
Somewhere at:

http://www.balabit.com/support/community/products/tproxy/

Thanks in advance.


On Wed, 2008-02-27 at 10:31 +0800, Ming-Ching Tiew wrote:
> 1. There are at least 3 different versions of tproxy kernel patches.
> 
>     Each tproxy kernel patch is quite strongly tied to a kernel version,
> 
> 
>    (A) Version Tproxy2
>    =============
>    For kernel 2.6.18
>    URL: http://www.balabit.hu/downloads/files/tproxy/obsolete/
> 
>    (B) Version Tproxy 4.0.x
>    ================
>     For kernel 2.6.22
>     URL: http://www.balabit.hu/downloads/files/tproxy/
> 
>    (C) Version Tproxy-4.1.0
>    =================
>     For kernel 2.6.25
>     URL: The "official website" is for kernel <=2.6.24
>     http://people.netfilter.org/hidden/tproxy
> 
>      but the actual version of tproxy 4.1 for 2.6.25 is here:
>      http://people.balabit.hu/panther/tproxy
> 
>     The kernel patch might work with nearby kernel versions, for example,
>     tproxy2 might work with kernel 2.6.19; however it will not work
>     will kernel 2.6.22 ( unless you port it ).
> 
> 2. Do not confuse tproxy kernel patch mentioned above with
>     squid user-space patches.
> 
>     So far the Squid ( 3.0 and 2.6 ) is only supporting on tproxy2 - the
>     userspace code is integrated.
> 
>     If you managed to compile Squid without changing the source,
>     perhaps with only minor changes in header files, meaning you are
>     likely either did not successfully link in tproxy support or at best it
>     is using tproxy2, and it will not work with tproxy-4.0.x and
>     tproxy-4.1.0 kernel counterpart.
> 
>     However, if you patch the squid source, you should be able
>     to get squid to work with tproxy-4.0.x and tproxy-4.1.0.
> 
>     You can look through the archive of this maillist to look at how
>     to port squid versions to support tproxy-4.0.x and tproxy-4.1.0.
>     Most of the patches floating around are not fully satisfactory,
>     but it could work, at least; but perhaps it will require you to have
>     some programming knowledge.
> 
>     Here maybe a good start :-
> 
> 3. All the tproxy kernel patches are not compatible with one another.
>     Each requires it's own way of setup and usage. So before doing
>     anything, check if you have gotten the correct info/tproxy version/patches.
> 
>     These are some of the info :-
> 
>      (A) Version Tproxy2
>      ============
>      The Squid documentation recommends this :-
> 
>            ebtables -t broute -A BROUTING -p ipv4 --ip-protocol tcp \
>                  --ip-destination-port 80 -j redirect --redirect-target ACCEPT
> 
>       This rule will "broute" bridge traffic from br0 to netfilter.
> 
>       The iptables rule will bring http traffic into local process  :-
> 
>              iptables -t tproxy -A PREROUTING -i br0 -p tcp --dport 80 \
>               -j TPROXY --on-port 3128
> 
>       To get SNAT working for tproxy2, there is a need for double NAT,
>        and here was the discussion and patch :-
> 
>           https://lists.balabit.hu/pipermail/tproxy/2007-October/000537.html
> 
>       (B) Version tproxy-4.0.x
>      ================
>       Requires additional patches for SNAT and FWMARK.
>       Some hurdles with bridge.
> 
>       Bridge problem is to do with packets must be marked PACKET_HOST when
>       heading for br0 as discussed in this tproxy maillist. There have been
>       people saying they will post the patch for it  but yet to date, there is none.
> 
>      This problem can be worked around by brouting the traffic into
>      the real devices instead of br0 :-
> 
>       INSIDE_DEV=eth0
>       OUTSIDE_DEV=eth1
>       ebtables -t broute -A BROUTING -i $INSIDE_DEV -p ipv4 \
>               --ip-protocol tcp --ip-destination-port 80 \
>                -j redirect --redirect-target DROP
>       ebtables -t broute -A BROUTING -i $OUTSIDE_DEV -p ipv4 \
>         --ip-protocol tcp --ip-source-port 80 \
>          -j redirect --redirect-target DROP
> 
>       Please note for real interfaces, it's  redirect-target DROP and
>       not redirect-target ACCEPT, while doing it on br0, it's
>       redirect-target ACCEPT !
> 
>       Remember to adjust your iptables rule accordingly since now
>       packets entering and leaving real  interfaces instead of br0.
> 
>       Example :-
> 
>        iptables -t tproxy -A PREROUTING -i $INSIDE_DEV \
>              -p tcp --dport 80 -j TPROXY --on-port 3128
> 
>       For tproxy-4.0.3 remember to apply the additional kernel patches
>       mentioned in this maillist or else the kernel will panic accessing
>       null pointer.
> 
>       (C) Version tproxy-4.1.0
>      ================
>       The ebtables/bridge notes above is equally applicable. However 
>       the iptables rules are totally different.
> 
>       Something like this will be required :-
> 
>            iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY \
>                   --tproxy-mark 0x1/0x1 -on-port 3128
>             iptables -t mangle -N DIVERT
>             iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT
>             iptables -t mangle -A DIVERT -j MARK --set-mark 1
>             iptables -t mangle -A DIVERT -j ACCEPT
> 
>             ip rule add fwmark 1 lookup 100
>             ip route add local 0.0.0.0/0 dev lo table 100
> 
> _______________________________________________
> tproxy mailing list
> tproxy at lists.balabit.hu
> https://lists.balabit.hu/mailman/listinfo/tproxy
> 
-- 
Bazsi