[FUG-BR] Tproxy no FreeBSD
Eduardo Schoedler
eschoedler em viavale.com.br
Quarta Abril 16 11:50:53 BRT 2008
O Tproxy tem 4 versões, dependendo do kernel que você for utilizar.
E-mail do pessoal da Tproxy:
"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 )."
Existem ainda patches para o IPTABLES e para o próprio squid.
O suporte que já existe no squid só funciona com tproxy2.
Se você quiser utilizar as versões B ou C, teria de aplicar um outro patch.
Veja:
"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."
Considerações sobre o IPTABLES:
"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"
Abraços.
--------------------------------------------------
From: "João Paulo Just" <jpjust em justsoft.com.br>
Subject: [FUG-BR] Tproxy no FreeBSD
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Olá, lista.
Vi em e-mails anteriores que pra repassar IP de origem no Squid era
preciso usar o patch Tproxy, pelo menos no Linux, pois ele não foi
portado pra FreeBSD ainda.
Procurei o fonte desse patch pra dar uma olhadinha e arriscar uma
estudada no código dele, mas não encontrei. Alguém sabe onde posso
baixar o Tproxy?
- --
João Paulo Just
Diretor Executivo - Justsoft Informática Ltda.
http://www.justsoft.com.br/
- --
Feira de Santana, BA, Brasil.
+55 75 8104 8473
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIBb44XL+vuN2d7ZwRApJiAJ9UNFlJ6hXP4Mx4p6jRb37BgDYh6gCeLvbM
WY5kik00veMvZUFHESBo3f0=
=Hsd3
-----END PGP SIGNATURE-----
-------------------------
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Mais detalhes sobre a lista de discussão freebsd