Re: [squid-users] transparent proxy in squid3

Dear Amos,

Thanks for your great hint of "tcpdump gets packets before any of the
iptables etc handling gets done to them" and " We have to rely on
ebtables/iptables LOG functionality for those bits"

Now I start debugging iptables, using
sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -j LOG
--log-prefix "TEST: "

from node-s (sender), we run [node-s (sender), 10.0.1.1, node-r,
10.0.2.1 (receiver), the squid3 machine is 10.0.3.1]

wget 10.0.2.1:8080

while we still see
"19:20:09.439059 IP nodes-links.40520 > noder-linkr.http-alt: Flags
[S], seq 4014254024, win 5840, options [mss 1460,sackOK,TS val
68449700 ecr 0,nop,wscale 6],"
in tcpdump, we see nothing in the iptables log

in contrast, if we run 'wget 10.0.3.1:8080' (directly connect to 8080
port of squid3 machine, although there is no service)
we see information in both tcpdump
"19:26:51.347175 IP nodes-links.41022 > nodec1-tblink-l9.http-alt:
Flags [S], seq 1779139991, win 5840, options [mss 1460,sackOK,TS val
68550176 ecr 0,nop,wscale 6], length 0
19:26:51.347287 IP nodec1-tblink-l9.http-alt > nodes-links.41022:
Flags [R.], seq 0, ack 1779139992, win 0, length 0
"
and iptables log
"
Mar 5 19:24:09 nodec1 kernel: [28094.303462] TEST: IN=eth0 OUT=
MAC=00:04:23:ae:cc:38:00:0e:0c:68:a8:58:08:00 SRC=10.0.1.1
DST=10.0.3.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=62692 DF PROTO=TCP
SPT=41021 DPT=8080 WINDOW=5840 RES=0x00 SYN URGP=0
Mar 5 19:24:09 nodec1 kernel: [28094.303495] TEST: IN=eth0 OUT=
MAC=00:04:23:ae:cc:38:00:0e:0c:68:a8:58:08:00 SRC=10.0.1.1
DST=10.0.3.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=62692 DF PROTO=TCP
SPT=41021 DPT=8080 WINDOW=5840 RES=0x00 SYN URGP=0
"

Can we conclude the error was happened due to
sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -j LOG
--log-prefix "TEST: "
cannot pick up the 8080 packet forwarded by the switch? Can some
packet loss happen before this step?

I am sorry I am not very familiar with the linux kernel/system...and
bother you so much trouble...

Thanks a lo!

On Mon, Mar 5, 2012 at 5:57 PM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
> On 06.03.2012 11:09, pplive wrote:
>>
>> Dear Amos,
>>
>> To see whether there were some internal firewall in my system , I
>> tried a simpler topology, i.e.,
>>
>> Client (10.0.0.1) (eth0) -> (eth0) Squid3 (eth1) -> (eth0) Server
>> (10.0.0.2)
>>
>> I just follow the setting in
>>
>>
>> http://freecode.com/articles/configuring-a-transparent-proxywebcache-in-a-bridge-using-squid-and-ebtables
>>
>> brctl addbr br0
>> brctl addif br0 eth0
>> brctl addif br0 eth1
>>
>> ebtables -t broute -A BROUTING -p IPv4 --ip-protocol 6
>> --ip-destination-port 8080 -j redirect --redirect-target ACCEPT
>
>
> "ACCEPT" on the layer-2 bridging is to handle the packet entirely at that
> low layer.
>
> It needs to be "DROP"ed out of the bridging layer into to iptables layer
> handling before NAT can change the IP/port and routing can shift it to INPUT
> path where Squid gets it.
>
>
>
>>
>> iptables -t nat -A PREROUTING -i br0 -p tcp --dport 8080 -j REDIRECT
>> --to-port 3128
>>
>> According to tcpdump, we can see the packets are forwarded to port 3128
>> (I use wget 10.0.0.2:8080 at the client)
>>
>> 14:04:50.282381 IP 10.0.0.1.33088 > 10.0.0.10.3128: Flags [S], seq
>> 388132433, win 5840, options [mss 1460,sackOK,TS val 1028407 ecr
>> 0,nop,wscale 6], length 0
>> 14:04:53.212426 IP 10.0.0.1.33088 > 10.0.0.10.3128: Flags [S], seq
>> 388132433, win 5840, options [mss 1460,sackOK,TS val 1029157 ecr
>> 0,nop,wscale 6], length 0
>>
>> Still, I am confusing of using one NIC, how can I redirect the packets
>> to port 3128.
>
>
> NAT is a special system which can change packets on both bridging and
> routing layers but does not itself make them change layer.
>
>  So what the above trace shows is that packets arriving are NAT/NAPT changed
> as they flow through the bridge. But not anything else.
>
>
> tcpdump gets packets before any of the iptables etc handling gets done to
> them. So its useful to verify that the packets are arriving and/or leaving
> the NIC as expected. but not much help deciphering what is happening to them
> in the middle around where Squid sits.
>  We have to rely on ebtables/iptables LOG functionality for those bits.
>
>
> I'm sorry I can't be of much more help. Beyond suggesting to try later
> versions of the software including kernel I've run out of ideas.
>
> Amos
Received on Tue Mar 06 2012 - 03:30:22 MST