[tproxy] Squid with tproxy extra brief FAQ - take 2
nantenaina Tianarivo
rivo at gulfsat.mg
Thu Feb 28 08:20:07 CET 2008
I have tried the patch for IP_freebind proposed here
https://lists.balabit.hu/pipermail/tproxy/2007-December/000638.html and
my squid could work with the tproxy4.
Before that it loaded the tproxy2 when compiled with
--enable-linux-tproxy
I hope it can help you.
Rivo
On mer, 2008-02-27 at 14:33 -0300, Eduardo Schoedler wrote:
> Thanks for the FAQ.
>
> I'm using the (B) Version Tproxy 4.0.x.
> However, I haven't found the patch for squid in the site
> http://www.balabit.hu/downloads/files/tproxy/.
>
> I'm using SQUID-2.6.17 with "--enable-linux-tproxy".
> But this compile options activates suppor for tproxy2 instead tproxy4.0.x,
> right ?
> How can I found the patch ?
>
> Thanks in advance!
>
> Best Regads,
>
> Eduardo Schoedler.
>
>
> --------------------------------------------------
> From: "Ming-Ching Tiew" <mingching.tiew at redtone.com>
> Subject: [tproxy] Squid with tproxy extra brief FAQ - take 2
>
>
> 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
>
> _______________________________________________
> tproxy mailing list
> tproxy at lists.balabit.hu
> https://lists.balabit.hu/mailman/listinfo/tproxy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.balabit.hu/pipermail/tproxy/attachments/20080228/821bef60/attachment-0001.htm
More information about the tproxy
mailing list