On 7/21/2012 3:15 AM, Ming-Ching Tiew wrote:
----- Original Message -----
From: Ming-Ching Tiew <mctiew@xxxxxxxxx>
rc.local attached.
Attachment rejected so re-post inline below :-
i got it all in the private mail.
#!/bin/sh
#
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don't
# want to do the full Sys V style init stuff.
touch /var/lock/subsys/local
ifconfig eth0 0.0.0.0 up
ifconfig eth1 0.0.0.0 up
brctl addbr br0
brctl addif br0 eth0
brctl addif br0 eth1
ifconfig br0 192.168.1.253 up
ip route add default via 192.168.1.1
MODE=tproxy
if [ "$MODE" = "tproxy" ]
then
ebtables -t broute -F BROUTING
ebtables -t broute -A BROUTING -i eth0 -p ipv4 --ip-protocol tcp \
--ip-destination-port 80 -j redirect --redirect-target DROP
ebtables -t broute -A BROUTING -i eth1 -p ipv4 --ip-protocol tcp \
--ip-source-port 80 -j redirect --redirect-target DROP
ebtables -t broute -A BROUTING -i eth1 -p ipv4 --ip-protocol tcp \
--ip-destination-port 80 -j redirect --redirect-target DROP
ebtables -t broute -A BROUTING -i eth0 -p ipv4 --ip-protocol tcp \
--ip-source-port 80 -j redirect --redirect-target DROP
i think you misunderstood the way bridge works any why you put the
DROP\ACCEPT rules.
because your whole script in intercept or tproxy modes are out of order.
since you are using the machine only as bridge and not Bridge+router
it's different thing about how you should look at it.
bridge works at Layer 2 level of packets.
there should not be a bridge loop!! such as one switch and the two NICs
connected to it (managed switch\VLANS is another story).
Bridge is a one way ticket for the packets.
requests for web pages comes only from one interface (unless you are
hosting a web server in the lan behind the bridge adn this is another story)
i dont know what in what side this 192.168.1.1 GW is sitting in the
network but for the example i will say that it sits behind eth1 interface.
i will give you a starter on bridge.
the idea is:
packet--> eth0-->
{````````````````}
{is this packet for}
bridge {me? if not me maybe }
thinkgs {someone on eth1? if so}
{transmit it to eth1 or}
{ me. else ignore the}
{packet. }
{````````````````}
packet in bridge ---> eth1--->gw 192.168.1.1
the ACCEPT rule of ebtables is the above logic.
the DROP rule of ebtables is actually another thing:
packet-->eth0-->BROUTE = DROP--> route\forward the packet using the
local machine firewall and routes rules.
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 DROP
and 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.
cd /proc/sys/net/bridge
for i in *
do
echo 0 > $i
done
iptables -t mangle -F
iptables -t nat -F
iptables -t mangle -F PREROUTING
iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT
iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY \
--tproxy-mark 0x1/0x1 --on-port 3129
iptables -t mangle -A DIVERT -j MARK --set-mark 1
iptables -t mangle -A DIVERT -j ACCEPT
ip rule delete fwmark 1/1 lookup 150 2>/dev/null
ip rule add fwmark 1/1 lookup 150
ip route flush table 150
ip route add local 0.0.0.0/0 dev lo table 150
for i in /proc/sys/net/ipv4/conf/*/rp_filter
do
echo 0 > $i
done
this is a very very wrong thing to do!
make a static decision.
if you want an intercept port use another one and make them both static
and dont play every boot "sed" with squid.conf.
sed -i -e 's/http_port 3129.*/http_port 3129 tproxy/' /etc/squid/squid.conf
else
# intercepting nat MODE
ebtables -t broute -F
ebtables -t broute -A BROUTING -p ipv4 --ip-protocol tcp --ip-source-port 80 \
-j redirect --redirect-target ACCEPT
iptables -t nat -F
iptables -t mangle -F
iptables -t nat -A PREROUTING -i br0 -p tcp --dport 80 -j REDIRECT --to-port 3129
sed -i -e 's/http_port 3129.*/http_port 3129 intercept/' /etc/squid/squid.conf
fi
the above are bad because you are doing the same mistake of which
declaring you dont understand how bridge works.
the "--redirect-target ACCEPT" is actually means: pass the packet to the
other side of the bridge or more precisely do transfer the packet to the
next levels of the bridge.
after all this a good way to understand bridges is:
http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html
have great diagrams and packets flows.
so the rules you actually need is:
ebtables -t broute -A BROUTING -i eth0 -p ipv4 --ip-protocol tcp \
--ip-destination-port 80 -j redirect --redirect-target DROP
iptables -t nat -A PREROUTING -m physdev --physdev-in eth0 -p tcp
--dport 80 -j REDIRECT \ --to-port 3129
if you are willing to be explicit.
byt actually only the iptables rules will be sufficient to make the
drill in intercept mode.
the bridge rule in this case is just to make it sooner a routing issue
then a bridge issue.
just as a note this diagram:
http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png
from left to right shows only two points in ebtables that can make your
clients get into squid.
link layer BROUTING (BLUE) or link layer NAT(green)PREROUTING.
# Default Fedora DVD installation has rules which must be deleted
iptables -D INPUT -j REJECT --reject-with icmp-host-prohibited
iptables -D FORWARD -j REJECT --reject-with icmp-host-prohibited
echo 1 > /proc/sys/net/ipv4/ip_forward
first try to change the settings to make them somehow genuine.
the next step is to understand that yahoo mail is mostly https traffic
which will not pass through squid.
if you do still get problems the it can be because of another network
issue that is related to the way you implemented your bridge in the
topology.
how this machine cables are setup? switch..router..client etc..
in my setup fedora 15 works ok.
it seems like another issue then squid itself.
if nat\redirect works fine in most cases it a matter of mac level
filtering since bridge do forward packet without mangling the src mac
address and while tproxy socket *DO* use the mac address of the src.
it seems like the wiki is indeed missing some explanation on bridge and
tproxy.
Regards,
Eliezer
--
Eliezer Croitoru
https://www1.ngtech.co.il
IT consulting for Nonprofit organizations
eliezer <at> ngtech.co.il
