TPROXY is turning out alright for most of our users. The iptables and
kernel changes seem to work perfectly. Thanks a lot guys.
We are just working our way through how it needs to fit into various
other network toolchains and re-documenting.
Two netfilter relevant questions have arisen:
The old one: How long until IPv6 TPROXY support is available?
The new one: How to configure TPROXY on a bridge?
Is anyone able to assist in providing a configuration change or a fix
that would get this going?
The info I have been given from the admin so far is this configuration
sort of works but is extremely slow at best. I suspect packet loops
somewhere, or maybe issues with related outbound streams which are not
spoofed:
ebtables -t broute -A BROUTING -i eth1 -p ipv4 --ip-proto tcp --ip-dport 80 -j redirect --redirect-target DROP
ebtables -t broute -A BROUTING -i eth0 -p ipv4 --ip-proto tcp --ip-sport 80 -j redirect --redirect-target DROP
iptables -t mangle -N DIVERT
iptables -t mangle -A DIVERT -j MARK --set-mark 1
iptables -t mangle -A DIVERT -j ACCEPT
iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT
iptables -t mangle -A PREROUTING -i eth1 -p tcp --dport 80 -j TPROXY --tproxy-mark 0x1/0x1 --on-port 3129
echo 1 > /proc/sys/net/ipv4/ip_forward
ip rule add fwmark 1 lookup 100
ip route add local 0.0.0.0/0 dev lo table 100
cd /proc/sys/net/bridge/
for i in *
do
echo 0 > $i
done
unset i
> Ok retested squid. Here are the scenarios and results
>
> 1. no ebtables--no entries in access.log squid server is only acting
> as a bridge.
> 2. with ebtables using ACCEPT for both source and destination--no
> entries in access.log squid server is only acting as a bridge.
> 3. with ebtables using ACCEPT for source and DROP for
> destination--entries in access.log squid slow to respond to requests
> 4. with ebtables using DROP for source and ACCEPT for destination--no
> entries in access.log squid server is only acting as a bridge.
> 5. original setup with ebtables set to DROP for both source and
> destination--entries in access.log squid slow to respond to requests
> 6. with ebtables only for destination set to DROP and no entry for
> source--no internet
> 7. with ebtables only for source set to DROP and no entry for
> destination--no entries in access.log squid server is only acting as a
> bridge.
> 8. with ebtables only for destination set to ACCEPT and no entry for
> source--no entries in access.log squid server is only acting as a
bridge.
> 9. with ebtables only for source set to ACCEPT and no entry for
> destination----no entries in access.log squid server is only acting as
> a bridge.
>
> According to testing the only way to get squid to work in bridge mode is
> either using scenario #3 or # 5.
>
> *scenario #3:*
>
> ebtables -t broute -A BROUTING -i eth1 -p ipv4 --ip-proto tcp --ip-dport
> 80 -j redirect --redirect-target DROP
> ebtables -t broute -A BROUTING -i eth0 -p ipv4 --ip-proto tcp --ip-sport
> 80 -j redirect --redirect-target ACCEPT
>
> *scenario #5:
> *
> ebtables -t broute -A BROUTING -i eth1 -p ipv4 --ip-proto tcp --ip-dport
> 80 -j redirect --redirect-target DROP
> ebtables -t broute -A BROUTING -i eth0 -p ipv4 --ip-proto tcp --ip-sport
> 80 -j redirect --redirect-target DROP
>
> Tom
Cheers
Amos Jeffries
Squid Project
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
