Search squid archive
Re: yahoo mail problem with tproxy (squid 3.1.19, kernel 3.2.21)
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
On 7/21/2012 6:01 AM, Ming-Ching Tiew wrote:
they indeed are not suppose to fail your setup but it's not suppose to be symmetric with tproxy. the idea of the bridge is that you have clients side and external side that you abuse both.----- Original Message -----From: Eliezer Croitoru <eliezer@xxxxxxxxxxxx> so what you just need for ebtables is two rules: all packets the are destined to the web om port 80.. route them into the machine... later will be intercepted by tproxy > so: ebtables -t broute -A BROUTING -i eth0 -p ipv4 --ip-protocol tcp \ --ip-destination-port 80 -j redirect --redirect-target DROPand every packet that comes from the internet from port 80 (web server) should be always get to the proxy as it's an > answer to squid request either tproxy or intercept. the only difference with intercept mode is that: the packet that comes back from the internet destination is the proxy and on any case the bridge will send it to the > proxy.so to intercept web answers to the proxy you need the rules: ebtables -t broute -A BROUTING -i eth1 -p ipv4 --ip-protocol tcp \ --ip-source-port 80 -j redirect --redirect-target DROP and that is it for the bridge.Your rules are essentially the same as mine and I don't see how it that different, maybe I am just missed the point. The reason you see many more rules than is needed because I want to make them the connection symmetric so that it does not matter which ethX is the upstream, and which is the down stream, ie whichever port you plug into it will still work. And I have specifically confirmed that the other two additional rules have no traffic.
if you make it this way for a purpose it's another story.i would say that the result can show some really nasty issue you are having in the network level and ebtables+switch is the basic thing to check.
i will try to dump the tcp sessions on the interfaces using: tcpdump -i any -X -s0 -n port 80 -w test.pcapi will be happy to look into the packets to see if there is a clue in them saying something about the "zero reply".
to make sure it's not squid issue try to install the rpm of squid 3.2 http://pkgs.org/fedora-16/fedora-i386/squid-18.104.22.168-1.fc16.i686.rpm.htmli have tested it on fedora 15-16 and still the same result that it works both on 3.1.X and 3.2.X.
you can try to play with stp on\off on the bridge for case of packets getting lost somewhere by STP filters.
Regards, Eliezer -- Eliezer Croitoru https://www1.ngtech.co.il IT consulting for Nonprofit organizations eliezer <at> ngtech.co.il
[Linux Audio Users] [Photo] [Yosemite News] [Samba] [Video Projectors] [Video Devices] [Big List of Linux Books] [LCD TVs] [Webcams] [Linux USB]